Oct 13, 2013

Escape Velocity for BW-on-HANA Projects

AUTHOR'S NOTE: Escape velocity (Ve) is the speed at which the kinetic energy + the gravitational force on an object is zero. Any speed above that will allow the object to break free from the gravitational pull of the larger mass. Ve is a combination of  G= gravitational pull; M=mass of the larger object; and r = distance from the center of gravity. Ve is used to launch rockets free from the gravitational constraints of planets, and it can also be used to leverage the gravitational mass as a slingshot -  where the gravitational pull of large bodies can actually be used as a slingshot for acceleration and escape. This is written as  

In our context the global desire is to escape from the dark pull of failure. Let’s call this the black-hole of failure.

Ve= Escape Velocity in BI projects (including SAP HANA BI) can thus be defined as


F is the pull towards failure as a constant (where the rate of failure is constantly balanced by the rate of success thus a point of accepted tolerance by business stakeholders and users). F can be more clearly understood where if a team delivers 5 successful reports (defined as reports that meet business expectations) and at the same time deliver 5 reports that do not meet business expectations- but are not punished by the system, governance or the business owners as a failure team the 0.5 is the balancing constant. Now if the team produces 4 successful and 6 not successful deliverables which begins a gravitational pull that is negative, or a pull that can crash either the developer of the team towards the black-hole of failure then a corrective action has to be taken at all points below 0.5. In our example if the team delivers 10 out of 10 reports that do not meet business expectations it assumes the developer or team reaches a 0 velocity and falls straight into the black-hole of failure never to emerge again. This is a perpendicular fall to oblivion.
P represents the propensity towards failure. This represents the negative mass of your black-hole, i.e. the pull of failure. P represents the place you don’t want to go. P also represents the failure probability with specific standards, processes and methodologies. P is often predictable when viewed through a scientific lens. For example if you have standards and processes that constantly deliver a 50% failure rate,  then your P factor has to be large whichever way you look at it.

n represents the center of negative gravity of the  dark planet and the lowest point of no return. At this point the trajectory of the developer and/or team has no recourse to getting additional budgets, additional chances or any recourse for another try. At this point managers are fired, partners are fired and individuals are fired. Of course in our example it is not the end of existence as the teams are simply replaced by another partner, manager and team – mostly in desperation, at far lower budgets, in very unplanned projects and with a lot of (n) negative pressure. 

I tend to be hyper-attracted to two Gartner findings on global BI.

Gartner in 2003 “50% of BI projects will not meet business expectations”
Translation: There is a very high probability that 50% of reports in your production environment are either not being used or will never be used by your business users.

Your takeaway: As you rush ahead at full speed understand that what got you here (i.e. a design that constantly delivers a 50% failure rate) should not be used to take you to the strategic HANA future

Your decision:
1.    Continue with the current standards and processes
2.    Continue with your current architects and modelers
3.    Continue with your current System Integrators

.. and reach the same point of failure where you currently exist only after deploying a net new acceleration technology

Gartner in 2013 “70% of BI projects will not meet business expectations”
Translation: In the 2012-14 period more and more customer are treating new technologies as Technical installations. While global spend on BI has gone up their propensity to failure has also increased. The current rate of failure is over 70%, from a 50% in the 2003-09 periods.

Your takeaway:
[1] HANA is a business solution and not a technology installation, what is the benefit of accelerating a 70 second query to 1 second if business will never use it
[2] There are many scientific ways to reduce the cost of your HANA migration anywhere from 20 to 60%

Gartner’s 2013 advice for big data projects “This is a time of accelerating change,  where your current IT architecture will be rendered obsolete,” Mr. Sondergaard, Gartner Sr. Analyst, said.  “You must lead through this change, selectively destroy low impact systems, and aggressively change your IT cost structure.  This is the New World of the (big-data), the next age of computing.”

Your decision:
1.    Find out how to leverage the scientific options of the IQDCT HANA methodology. Increase Quality, Decrease Cost and Time
2.    Build net-new global HANA standards and processes and then seriously consider moving greenfield to BoH (BW-on-HANA)
3.    Build net-new global HANA FEDW (Gartner architecture) and leverage automated HANA modeling
4.    Consider changing your current System architects, design planners and even your SI, i.e. there is adequate data that proves that existing folks will only follow existing / familiar paths. If you leverage existing resources then they will take you only on a predictable path, i.e. 70% failure. If this were not true then they should have taken you on a path of Escape Velocity way before you read this paper.
5.    Consider merging your many BW system on a global FEDW architecture. Benefit 100% central governance, with 100% local independence. Ability to detach a business unit for this environment over a weekend without disrupting any other central or local business unit.

.. and reach the same point of failure where you currently exist only after deploying a net new acceleration technology


 Leveling the playing field: It has been clearly established that successful BI projects experience a higher acceleration that is directly related to the degree of success. Acceleration here is measured by satisfied business users, lower spend per project, fewer unplanned projects, happier stakeholders that view BI as an investment, easier budgetary allocations and a high degree of trust – competency of the IT team to deliver results.

On the other hand it is similarly established that failed BI projects experience a drastic slowdown proportional to their degree of failure. Deceleration here is measured by more dissatisfied users, higher budgetary allocations due to trying to fix failed deliveries, higher number of unplanned projects due to lack of meeting business expectations, disappointed stakeholders that start to view BI as an expense, difficulty in getting new budgets approved due to a total lack of confidence in the team to deliver any business results – lack of business confidence in the delivery team.

Examples of F in existing BI environments are totally measurable. Take an inventory of every report in your production BI environment. Drop them to an excel sheet. Separate them by Business function, i.e. FI, OTC, P2P, SCM, etc. Place all the FI reports into one worksheet, OTC into another and so on. Create three columns [1] Can use as is- do not change; [2] Can use but needs change; [3] cannot use please delete. For each report that can be used as-is score a +1; for each report that needs change score 0; for each report that cannot be used score a -1. Then come and post your score on this URL for a global BI Score of F. Enter your email if you want results shared. No company or individual details will ever be share and your input will be in strict confidence.

Examples of F in new BI projects, i.e. not yet live, are also measurable. Take an inventory of every report that your SI partner plans to deliver. Apply the same rules as above and get your users to fill the three columns as above. In this case most of your users will not be able to accurately score the individual reports but you will still get a trend that will be highly beneficial. You will find out quite early what your probable F factor is. Once you go live conduct the same exercise around 30-60 days after go live, as by this time your users will understand the usability of each report and its direct business benefit or lack of it thereof. Compare the two and we once again get very interesting results.

Examples of P in existing projects is scientifically predictable. Your partner’s P score determines the speed at which your partner will pull your HANA BI project towards failure. The pull is a a gravitational pull based on the mass of defective procedures and methodologies that come with a partner. It is the combined score of their recommendations and methodologies. If your partner recommends a HANA installation as a technical installation then score them -3, and so on and so forth. If your partner simply delivers what the client asks them without any scientific inputs or forecasts then socre them -4, i.e. when a pharmaceutical company asked a leading SI to simply replicate 100% their 1998 Cognos reports on to the new HANA plus BusinessObjects 4.0 platform. This was as much the fault of the customer in firstly demanding legacy reports and for the partner in simply accepting a P factor with a very high mass, i.e. the probability of absolute failure was extremely large. In order to get your own propensity score, i.e. the propensity of your current SI, or their recommendations, request your P questionnaire and get your own propensity mass of your black-hole. The bigger the propensity mass the faster this black-hole will pull your strategic success towards failure, the faster you need to travel towards success as your escape velocity.

Examples of n in existing projects is scientifically predictable. In our above example of Cognos the SI ended up providing over 6 months of services in a fixed bid contract – total loss. Even after 6 months the customer had to cancel the project as the very foundations of the project were erroneous. The pull of the large mass of failure was disproportionally large and at a certain point all parties know that Ve could not be achieved. Could this have been predicted – absolutely right before the project had even started.

In yet another example a SI went and delivered over 500 reports. Within 20-30 days the business users realized that the deliverables were not going to meet their expectations, by day 40 businesses reverted to their old reports and stopped using the new BI environment. By day 50 our team was invited with a single statement ‘How can you help get business confidence back in BI’. Upon analysis we found that the methodology, standards, processes and resources were all wrong- so the next project started with a total replacement and rebuild of the BI environment but one-step-at-a-time. Success went from 12%, i.e. 88% failure, to 92% user satisfaction in a matter of 4 months.

So understand Ve, work towards it and measure if your trajectory can release you from the mass of failure and launch you to your goal of success.

In this example the impact of, or resistance caused by, bad decisions of managers and/or inexperienced resources is not taken into consideration even though it has a profound impact on the total Ve of BI projects.
In addition Escape Velocity is a misnomer as it is not any particular velocity but a relative speed that is dependent on the distance from n, or the negative mass of failure. The farther away from P that we are the lesser speed we need to apply to attain Ve, at a certain distance from failure one can remain perpetually free from the negative gravitational pull of P.

Quantifying the HANA BI Escape Velocity

By simple scientific rules
n: is the point of damnation and the center of the mass of failure. It is also the absolute point of no return. No amount of budgets or efforts can make the project escape failure.
The Red circle is the point of escape. The lower your project flies the more energy (budgets, resources and efforts) the project will require to simply remain afloat. The degree of failure (Gartner says this is 50% to 70% right now) determines the point of location on the E1 axis.
The Green circle is the point of survival or equilibrium, at which point the gains are fully sustained with minimal efforts. This is the point launch to Ve. The degree of survival is determined by the point of location between the surface and the green circle represented by E2
E3 is the point of escape velocity, where with a minimal effort BI projects can soar to high degree of success, very low wastage and minimal efforts to attain high gains.

What’s on your roadmap… can you see past the horizon or do you never look beyond your feet..