In a previous article we looked at delivering disruptive technologies by developing a new product to replace an existing product. We touched on the impacts of replacing an existing product with a new product. The alternative is to incorporate disruptive technologies into existing products – a daunting task, fraught with risk and danger!
SAP is one of the leaders in ERP (Enterprise Resource Planning) systems. They provide several interesting examples of how to develop and deliver disruptive technologies. Let’s look at how they are building disruptive technologies into their products:
Perhaps the most complex and critical systems in use today are the ERP systems that provide the backbone of all large companies, most medium size companies, and many small companies. ERP systems are highly integrated across the company and touch all parts of the company. If the ERP system goes down, the company can’t build or ship product – or collect money, pay suppliers, pay employees, comply with regulations, plan business, or track the market. ERP is literally the definition of mission critical. ERP systems have lifespans of decades. They are continually evolving and adding new capabilities, all while maintaining compatibility and stability. They are also heavily customized for each customer, and sit at the center of an ecosystem of applications built around company data.
An ERP system is fundamentally three components.
- A datastore of all information created or used by a company.
- A set of functions and applications that create, update, use, or add value to this information. The two primary uses are updating the data through transactions and using the data for analytics. These two use cases place very different demands on the underlying datastore.
- A set of controls on who can access and manipulate the information and applications.
At the heart of an ERP system is the datastore. Traditionally this is a SQL database. The size of ERP data, performance requirements of the applications accessing this data, and the critical requirements of data integrity have driven the high end of the database market. Only a few databases can scale to the levels required – most notably Oracle, although other databases are also used.
As the use of ERP and ERP data has grown, the style of access has grown from batch processing to OLTP (OnLine Transaction Processing), to interactive queries and reporting and stream processing. SQL databases are great for batch and OLTP, but are not as well suited to many popular queries or stream processing.
As a result ERP data has been divided between an OLTP database, typically an SQL database, and copies of this data in forms better suited to analytics. This Analytics data is typically stored in data lakes, Business Intelligence data cubes, and similar query focused formats including non-SQL databases.
Using multiple technologies to contain what is essentially the same data is bad for data integrity, for avoiding stale data, for integration, and bad for the increased cost of maintaining multiple technologies and applications. Using the same ERP datastore for both transactions and analytics has been a long term goal – one that could not be met with existing technologies.
From a business perspective, SAP and Oracle are competitors. The Enterprise level SQL databases that can support large ERP systems are extremely expensive and represent a large part of the cost of ERP systems. The ERP database is the central integration point for all corporate data – many applications using ERP data will integrate with the database itself rather than directly with the ERP system.
All of these factors made it attractive for SAP to be able to offer a new technology for storing ERP data – a disruptive technology that would replace the traditional SQL databases and other forms of data storage in ERP systems. The next article will cover what SAP did from both technology and customer perspectives.