The previous article introduced ERP and touched on some of the challenges around using the huge amounts of data that ERP requires.

SAP developed a new technology called HANA. Unlike a disk based SQL database, HANA is entirely in-memory (with a disk based backing store for backup, recovery, and data archiving). Unlike the row oriented SQL model, HANA is a hybrid row/column datastore which supports high performance queries and analytics. HANA is also a compressed data store – in addition to allowing a complete ERP database to fit into memory, the compressed data can also be searched and transferred more quickly.

Enabling this software was the development of large servers from companies like Dell, HP, and IBM with dozens of processor cores and 10+ TB of physical memory. Since the introduction of HANA servers have continued to grow – today you can get servers with over 100TB of physical memory! There are other developments now emerging which will radically grow the amount of memory that can be attached to a server and which will lower the cost of this memory. In short, an in-memory approach has proven to be better than on-disk.

HANA provides dramatic performance improvements as well as new capabilities – it is a disruptive change at the very core of ERP. SAP wants to use HANA as the foundation of all ERP deployments, replacing all current databases.

Consider how SAP has implemented and deployed HANA:

Much of the architecture of HANA is designed to support analytics. So, analytics applications were the first target for HANA. Like other ERP Analytics implementations, data would be extracted from the OLTP database, stored in an analytics database (HANA in this case), and used by analytics applications.

Analytics applications would be developed and modified to take advantage of the new capabilities of HANA. Over time more and more analytics applications would begin to use a single HANA datastore.

At the appropriate time, HANA would also be used for OLTP. This would initially be done for customers with special needs and mainly targeted at new installations.

Finally, HANA would be offered as a single datastore for mainstream customers.

Note the incremental approach which is key to successful deployment of disruptive technologies:

• Start with an application that benefits from the unique capabilities of HANA, has minimal requirements for broad features and integration, delivers business value to a relatively small set of users, and is outside the mainstream use cases. This provides immediate business value from a limited set of capabilities and allows you to improve and mature the technology in a constrained environment. At this point it is critical to minimize the impact of failure and to provide an opportunity to grow and extend the technology.
• Over time add additional analytics applications, either by developing new applications that are now feasible or by modifying existing applications that benefit from the unique capabilities and performance of HANA. Test and extend HANA with each new application, and don’t release any applications until they and HANA work well together.
• Once HANA proved itself with a core set of analytics applications add more applications. Over time the focus moves from applications that need HANA capabilities to the business value and cost savings of having a single datastore for analytics.
• HANA fully supports the SQL model used by the current databases. It can be treated as  “just another SQL database” and requires minimal modification of the rest of the system. This allows SAP to begin to use HANA with minimal changes to the ERP ecosystem built on top of the database.
• Next, begin to deploy fully integrated ERP systems that use HANA as the single master database for both transactions and analytics. The initial targets will be specialized companies that are “relatively simple” as far as ERP goes.
• At this point you can begin to use HANA for new customer deployments. These customers will start with a fully integrated system. This is the entry of HANA into the majority market.
• Next focus on moving existing customers to HANA as part of major version upgrades of the ERP system. Major version upgrades are expensive and time consuming. They require significant migration and integration work, and provide an opportunity to introduce new technology. At this phase you are addressing the Early Majority market.
• The next step is to make HANA the standard choice so that it is simply part of all new systems and upgrades – anything that is not HANA based becomes an exception. You are now addressing the Late Majority market.
• Finally, retire the older versions of software that do not support HANA. Over time phase out support for these older versions. This will encourage the Laggards to move to HANA based systems.

SAP has a long timeline for customer adoption. SAP understands the impact of major changes on their customers, partners, and ecosystem. HANA was initially introduced in 2008 and the current target for full customer migration is 2025 – a 17 year migration!

You can see how this approach starts with Innovators and then moves through Early Adopters, Early Majority, Late Majority, and ultimately laggards.

SAP HANA is a good case study on how to successfully integrate and deploy a disruptive technology in an existing product in a mature market.

Next: Case Study: Incorporating Disruptive Technologies into Existing Products (part 3)