9 September 2020

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

Fifteen years ago, I joined a sales call at Maanshan Iron and Steel Company (Masteel, or Magang in Chinese) in Anhui Province, China. Our team was ushered into a large conference room where a gigantic management dashboard was on prominent display. It had real traffic lights, gauges the size of grandfather clocks and light-emitting diode (LED) messages showing key performance indicators (KPI) for the hulking steel plant next door.

After several hours, as our meeting was wrapping up, I noticed that none of the lights, dials or messages glowing on the dashboard had changed at all. When I enquired about this, I was told that they were only updated at the end of each day by an employee who keyed in the data from a paper report.

Therein lies the key challenge of business analytics: synchronizing and visually representing data from numerous sources to provide insights on what is happening in real time.

Transactional Versus Analytical Processing

Enterprise resources planning (ERP) systems like GM-X ERP for Blockchain are a logical source of data for the information displayed on a management dashboard, because they are typically implemented to cover the entire scope of a business and are updated continuously throughout each working day. But their underlying databases are designed for high-speed online transaction processing (OLTP). As anyone who has ever created a pivot table in Microsoft® Excel® can attest, this is a far cry from the online analytical processing (OLAP) required to produce management reports and represent them visually on dashboards.

In brief, OLTP applications like ERP systems are designed for concurrent use by hundreds or even thousands of people at a time. Their key performance requirements are system availability, transaction throughput, data integrity and recoverability. OLAP applications, on the other hand, are designed for a relatively smaller number of people who need to consolidate data (roll it up), drill down to specific details, slice specific data sets and then view (dice) those slices from different points of view ― instantly and on demand.

Limitations of Conventional Databases

Conventional OLTP databases which store information on disk typically aren’t fast enough for OLAP, because a well-designed OLTP database keeps the amount of consolidated data on hand at absolute minimum. People who need OLAP must patiently wait for the system to consolidate their data in order to gain the latest top-down view required for drilling down, slicing and dicing. For the same reason, conventional OLAP databases which store information on disk would be notoriously slow for people who need OLTP for mission-critical activities like taking and filling customer orders, processing payments and locating stock.

Until recently the only realistic way to resolve this dilemma was to consign the OLAP databases to a separate data warehouse, and access them using business intelligence (BI) applications instead of ERP systems. But this approach has its own problems. To keep their ERP systems running at the pace of business during peak hours, most businesses wait until off-peak times to update their data warehouses ― just as Masteel was doing at the end of each day fifteen years ago. For them, the goal of providing insights on what is happening in anything resembling real time seems an impossible dream.

SAP HANA In-Memory Database

Ten years ago, the German software maker SAP® SE shipped its first release of the SAP HANA® database, which had been in the works for several years and was first demonstrated in 2008. Unlike conventional databases, HANA (which stands for “High-Performance ANalytical Appliance” or, alternatively, for “Hasso’s New Architecture” after SAP co-founder Hasso Plattner, whom I have met) is an in-memory database which can process analytical queries 4,000 times faster on average, and transactional queries between 100 to 1,000 times faster, than any traditional relational database management system (RDBMS).

This means that a single SAP HANA “OLTAP” (online transaction and analytical processing) database engine is capable of supporting both the OLTP and OLAP requirements of business enterprises in real time. There’s no need for them to wait until off-peak times to update their data warehouses. In fact, most don’t need a separate data warehouse at all.

SAP has doubled down on its new database platform by upgrading most of its software offerings, including SAP® Business One® and SAP® Business ByDesign®, to run on the HANA database ― and, for some, it’s going a step further by requiring customers to use HANA in the future. For instance, the next generation of SAP’s ERP software for large enterprises is branded “S/4HANA®” and runs exclusively on the HANA database. Last February SAP announced that it will discontinue support by 2030 for the ERP Central Component (ECC), also known as the SAP Business Suite ― which allows customers their choice of RDBMS, including HANA ― and customers who don’t move to S/4HANA by 2027 will be transferred automatically to a more expensive maintenance model.

The world’s third-largest software company also sees a bright future for HANA beyond its own enterprise applications. According to Computer Weekly, “Plattner declared SAP’s plans to extend Hana’s reach … adding that SAP has embarked on a development path to ensure Hana can address the challenges associated with the growing heaps of data.”

We have to digest much more data inside a Hana system if Hana is to become a database outside the ERP space. Hana is too good a database to lock inside SAP enterprise applications.

― Hasso Plattner, SAP co-founder

SAP has made good on this promise by releasing developer tools that allow software written in PHP and utilizing standard structured query language (SQL), such as the GM-X ERP for Blockchain application, to store and retrieve data using a HANA database. Crucially, licensing those tools from SAP allows developers like us to retain all ownership and intellectual property rights in the applications we create.  

RDBMS Choices for GM-X ERP for Blockchain Application

At Geoprise, our longstanding philosophy is that a database is a container ― albeit a vital one ― to be used for the storage and retrieval of data, whereas the application is the place for all business logic. Our rapid application development framework uses standard SQL and avoids, as far as possible, any non-standard proprietary extensions such as triggers, stored procedures and constraints. This means that the GM-X ERP for Blockchain application will run on any SQL-compliant database for which a data access object (DAO) is available. We currently offer DAOs for the following:

  • Microsoft SQL Server® 2008 R2+
  • MySQL® 8.0+
  • Oracle® 10g+
  • PostgreSQL v8+

With this posting we are announcing future support for the SAP HANA database 2.0, SPS04+ as well. This will make GM-X ERP for Blockchain the first and, as far as we are aware, the only non-SAP ERP system in the world to run on the SAP HANA database.

We expect to roll out our DAO for the SAP HANA database within four months, during the fourth quarter of 2020.

What SAP HANA Capabilities Mean for Our Customers

Concurrently with the release of our DAO for the SAP HANA database, Geoprise will be releasing an enhancement to our Menu subsystem which gives our customers the option to display real-time dashboards on the GM-X Home Page, with drilldown to transactional data. Role-based permissions already available with the Menu subsystem will control which charts are visible to each user, as depicted in Figure 1.

GM-X Home Page with Real-Time Dashboard

Figure 1 – GM-X Home Page with Real-Time Dashboard

This feature inevitably raises concerns about how long it will take to load the Home Page. No matter how visually appealing and useful dashboards may be, users will reject them if they have to sit and wait, even momentarily, while the GM-X system refreshes their charts.   

In reality many factors will determine the time it actually takes to load a Home Page containing a dashboard. These include:

  • The number of charts on the dashboard;
  • The complexity of the database queries which must be executed in order to draw each chart;
  • The volume of data which must be queried to draw each chart;
  • Whether data is extracted directly from the GM-X OLTP database, or from an OLAP database (data warehouse);
  • The current workload of the GM-X application server and database server; and
  • The speed of the database server.

As I explained earlier, if the data needed to draw a chart comes from an OLAP database or data warehouse, to keep the GM-X ERP application running at peak performance our customers will need to strike a balance between users’ needs for real-time data on the one hand, and the waiting time (latency) before events are recorded in the data warehouse on the other. 

Broadly speaking, our customers who use the MySQL or PostgreSQL database engines for their GM-X ERP application, and want to minimize latency by pulling data directly from those databases when drawing charts, may need to keep their queries relatively short and simple, and limit the number of charts which appear on the Home Page. That’s because those database engines don’t store any data in main memory like SAP HANA.   

Customers who use the Microsoft SQL Server or Oracle databases for their GM-X ERP application may be able to utilize in-memory features introduced by those vendors in 2014 to counter SAP’s competitive threat. The Oracle database has an in-memory option, available with Oracle 12c and above, which requires payment of additional license fees. Microsoft SQL Server 2014 introduced memory-optimized tables and, with SQL Server 2016, imposes no limit on the size of those tables.

If none of these options are suitable, customers for whom OLTAP capabilities are mission-critical will soon be able to run their GM-X ERP application on the SAP HANA database. It’s more expensive than a conventional RDBMS, to be sure, but for them the benefits of visually representing data from numerous sources to provide insights on what is happening in real time will far outweigh the cost.

Importantly, our customers won’t have to re-implement their GM-X ERP application to take advantage of the SAP HANA in-memory database. Other than the new DAO and enhanced Home Page, which Geoprise will ship automatically to all our customers under maintenance, every other part of the GM-X ERP application will remain unaffected and will continue to run exactly as before. Of course it will be necessary to migrate existing GM-X databases and tables from the old database engine to the new, and reconfigure the GM-X database connections, but this procedure will entail little risk of business disruption because no data reorganization or restructuring will be required. The GM-X database schemas for SAP HANA will be exactly the same as for all the other database engines we currently support.

Licensing and Deployment Considerations

To run the GM-X ERP for Blockchain application on the SAP HANA database, Geoprise customers will need to procure a full use license from SAP. Runtime licensing, which is only available for applications published by SAP itself, is not an option.

Full use licensing is available for the SAP HANA Base, Platform and Enterprise editions. According to SAP, our customers can even use the SAP HANA Express edition in production, for free, with up to 32 gigabytes (GB) of memory.

The SAP HANA database engine runs exclusively on Linux® operating systems including SUSE® Linux Enterprise Server and Red Hat® Enterprise Linux® (RHEL). The Express edition will run on a virtual Linux machine installed on a Microsoft Windows® or Apple® Mac® computer. These prerequisites pose no problem for the GM-X ERP application, which runs on either Windows or Linux/UNIX servers. Most often, our customers deploy the GM-X ERP application on a different physical or virtual machine than the database, and in this case ― unlike Microsoft’s PHP driver for SQL Server, which works only on application servers running Windows ― SAP’s PHP driver for the SAP HANA database works on either Windows on Linux/UNIX application servers.   

Our customers have the option to run the SAP HANA database on-premises as an appliance available from various SAP-certified hardware vendors, or in the cloud through various Infrastructure as a Service (IaaS) providers including Amazon Web Services, Microsoft Azure® and Google Cloud Platform™.

SAP Certification

At present, SAP offers Third-Party Application on SAP HANA Certification (HANA-APP) for traditional client-based scenarios, where an application such as GM-X accesses the SAP HANA database using SQL through the Open Database Connectivity (ODBC) interface provided by SAP’s developer tools.

It’s also possible for us to offer our GM-X ERP application for SAP HANA at the SAP App Center. We can do this with, or without, HANA-APP certification.

It is our intention to cautiously explore both avenues because we are mindful that SAP probably regards our GM-X ERP application as a competitive product.

Conclusion

We think this announcement is exciting news, so please stay tuned for our general availability announcement in about four months’ time.

After all these years, I’d love to journey back to Masteel in China and show them how they can use our GM-X ERP for Blockchain application running on the SAP HANA database to light up their dashboard in real time ― or, better yet, put it on everyone’s PC screens, tablets and smartphones so they can see KPIs in real time wherever they may be.

Amazon Web Services is a trademark of Amazon Services LLC in the United States. Apple® and Mac® are registered trademarks of Apple Inc. in the United States and other countries. Google Cloud Platform is a trademark of Google, Inc. in the United States and other countries. The term “Linux” is a registered trademark of Linus Torvalds, the original author of the Linux kernel. Microsoft®, Excel®, Azure®, Windows® and SQL Server® are either registered trademarks or trademarks of Microsoft Corporation in the United States and other countries. Oracle® and MySQL® are registered trademarks of Oracle Corporation and/or its affiliates. Red Hat® and Red Hat® Enterprise Linux® are registered trademarks of Red Hat, Inc. or its subsidiaries in the United States and other countries. SAP®, SAP HANA®, S/4HANA®, SAP® Business One® and SAP® Business ByDesign® are registered trademarks of SAP SE in Germany and in several other countries. SUSE® is a registered trademark of SUSE LLC or its subsidiaries or affiliates. Any other product names referenced herein are used for identification only and are, or may be, the trademarks of their respective owners.

Tags: