Wednesday, February 10, 2016

The Tower of Hanoi Fallacy

The drive behind pursuing upward value chain motion is commendable in the the eyes of the shareholders. However, it often result in a costly failure or worse becoming a zombie company (Yahoo...). Most of the time, such approach fail because corporations do not understand and satisfy the core requirement driving the Innovate - Leverage - Commoditise strategy via leveraging a real ecosystem play. As a result, companies end up deploying brittle strategy with very weak underlying gameplay which under perform in a highly competitive market.
One of the main reason behind the failure of such strategy is company's lack of customer's ecosystem understanding. Software vendors, by example, have the false sense that they understand the use of their competencies (database systems or ERP) beyond the customer horizon. They regularly misunderstand the higher level of the stack valued by customers. SalesForce customers do not care if the underlying DB is from Oracle or SAP Hana. In AWS case, nobody care they run Xen, KVM or VmWare. This is perfectly illustrated in the cloud value chain mapping bellow. The only important parts is the last layer exposed to the customer itself. Anything under it is just the submerged part of the cloud iceberg.






Additionally, companies do not only fall prey to the Stack Fallacy. Sometimes, rather than (just) trying to move up the stack, corporation try to also move laterally in a bid to absorb adjacent stack. Large software vendor (ex: Oracle & SAP) are quite attracted to this tower of Hanoi play as look to force their way into a parallel stack with alternative business models. Recently these very large software corporation embrace such strategy by trying compete directly against IaaS and PaaS solution rather than co-opting them
These large companies tend to have a seemingly good awareness of their competences based on the resources and knowledge that they gathered via their marketing departments, sales teams, R&D dept, etc.. This awareness allow them to maximise revenue from the software value chain (mapped below, interpretation and trimmed down version of the software value chain by Pussep and Al.) .




However, these companies have build enormous revenue base on this type of value chain. And, transitioning to a different consumption model generate a struggle originating from the financial implication of transforming from licensing to SaaS model combined with the self cannibalization of their existing revenue streams. Basically, they cannot (out)innovate competition from the market they transfer into due to internal financial tension.

Moreover, while they have a good understanding of their value chain. They often completely underestimate the new one they need to adopt. The assumption is that it is just another Tower of Hanoi play.

Rather than co-opting existing platform by building as a customer on top of the cloud value chain they suddenly need to expand their capabilities in order to internalize the new requirement. You can see in the diagram below the daunting challenge they are facing. Not to mention they still require to maintain their old revenue streams in order to transition. This bipolarity is not without reminding Gartner Bimodal strategy, which if often considered to be harmful.




As a result without situational awareness, it is easy to fall prey of the Tower of Hanoï fallacy as it is near impossible to achieve:
  • transition to a new value chain
  • acquisition of new technical skills/knowledge
  • expand new market and business model understanding
  • compete with ecosystem natives
  • manage revenue stream self cannibalization.


You might ask what type of play these behemoth (SAP - ORACLE) should adopt? Here is a very succinct possible strategy based off Wardley IBM vs Aws play.
  1. Target a proxy / platform play by leveraging the inherent inertia of their customers. Hint : lifespan of SAP ERP solution average 15 years.
  2. Provide a AWS/Azure/GooG cloud proxy service for customer and third party ISV. Their customer are looking for stable, robust and reassuring solution for the backbone of their enterprise. Providing an first safe path for extension of "legacy" on premise solution with external cloud service (even and especially not their own). And second a migration path for full blown cloud deployment.
  3. Play the platform play card but without recreating their own cloud IaaS. SAP & Oracle have already something in that domain which should help make the transition as long as ego don't get in the way. Then encourage the rest of their ecosystem to join while focusing on operational excellence. To be honest they have such a massive ecosystem it is surprising they didn't try to push this further already. Moreover, leveraging Cloud foundry is also another option, however this might be too late for this.
  4. Monitor the growing ecosystem in order to spot successful emerging services. Acquire them rather than copying them in order as in the beginning it is all about ecosystem expansion rather than commoditization. This will help create confidence in the solutions as well as attract newcomer with the potential promise of future acquisition.
  5. Offer a form of cloud insurance market solution for as a long term pay. They can leverage it to expand their data mining capabilities while satisfying the customer risk averse need.