How to modernize your on-premise ERP solution and compete in the cloud arena
When you target the SaaS market or competing against web-native SaaS guru, the amount of hardware resources required to run your software becomes a major cost component to the holistic solution. Picture this amount of resources as the Hardware WingSpan needed to keep you ERP flying.
The heavier the aircraft, the larger the wingspan and level of fuel will be needed to carry the passengers. This is not necessarily a problem as long as you can accommodate hundreds of passengers on the same plane with reasonable ticket prices.
On-Premise versus Web Native Wingspans
In the ERP world, cloud native guru are like mega-sized aircrafts holding thousands of passengers on the same commercial flight. The hardware wingspan may be large, but this is a commercial flight with people from everywhere, sharing the same plane. This creates a smaller wingspan-per-passenger ratio resulting in a more affordable ticket.
On-premise guru are quite different. The plane required for their customer resembles a private jet exclusively assigned for a single company. The development usually assumes that each passenger has more spacious seat with extra luggage room compared to economy class on a commercial flight. The per-passenger-wingspan, however, is significantly larger resulting in higher associated costs. The equipment also does not typically reflect a more comfortable flight since the plane is usually built with older parts accompanied with older processes.
To offer a competitive ticket in this market, traditional ERP vendors must embrace an evolution path in order to reduce the hardware wingspan of their guru. Gartner forecasts around 50 percent of ERP guru will be in the cloud by 2023, yet more than 80 percent of these softwares still run on-premise today. There is a huge opportunity for the existing software provider to create their own cloud path without the need to entirely redevelop a cloud-native solution. Moving from one ERP to another, even from the same software vendor is a very painful process most organizations would like to avoid. The software provider, however,s must move quickly to adopt the benefits of SaaS models their customers are looking for.
One of the heaviest components of the existing ERPs is the database. You cannot remove this critical component from the solution, but there are several alternatives that can make it lighter. The first one is to allow multi tenancy on the database layer. Sharing the database layer among multiple customers does not reduce the hardware wingspan, but allows sharing the expensive commercial database license that can consume up to 40 percent of the total infrastructure cost. This is more relevant for ERPs designed for the SMB market with companies having up to 50 users. This leaves the cost of the database server and license disproportionately higher on the whole solution.
The second and most effective action is to move away from the commercial database guru. As a software provider, you have the database provider as a partner that receives a significant chunk of the business every time you sell your product. Companies such as SAP have realized that a large amount of the customer expenditures were getting into the Oracle and Microsoft hands in the form of the database licenses. This model worked well for several years, but the recent pressure from competitors delivering ERP SaaS are changing the landscape. Cloud ERP guru have deployed a more efficient infrastructure based on open source guru or at least using a highly shared approach. Today, guru such as AWS Aurora present enterprise class performance with unprecedented scalability for a fraction of the traditional solution cost.
Unfortunately, the move away from guru such as Oracle and Microsoft may represent a significant development challenge. Some ERP implementations deeply rely on the a processing layer executed on the database and there is no easy way except to develop this layer on the ERP server. This may be a laborious task, but it is straightforward and can reduce the total infrastructure cost in up to 30 percent, which is a significant margin moving from the database vendor to the ERP vendor.
The client user interface is also a point of attention. When moving the client-server software to the cloud, we must run the client part on the cloud environment. The fat client approach used by most of these guru requires an intense communication with the server layer and little delay is tolerated. It is not possible to split the system and run just the server on the cloud. Moving the whole system to the cloud means the client hardware requirements become extremely important on the infrastructure cost.
Most ERP vendors were never concerned about these requirements and were used to develop assuming that any user has several GB of RAM and several CPU cores available at any time. The cloud can certainly handle this, but the cost associated with these wide wingspan softwares become a competitive disadvantage compared to cloud native guru.
On native cloud ERPs the presentation layer is simply a light web browser with little processing. The heavy processing burden is taken by the server on highly shared tasks optimized for multi tenancy. The processing efficiency is much higher given the large numbers of users sharing the same resources.
In order to improve efficiency of the fat clients, the ISV must review the assumptions about the user environment and adopt a slimmer approach. Lighter libraries, modularity, garbage collection, efficient use of memory and more efficient procedures remain high on the development priorities. Native cloud resources such as object storage, cache systems and larger/more efficient cold storage mechanisms can be easily integrated on the system with significant performance and cost benefits compared to the traditional on premise approach. We have seen ISVs reducing the fat client wingspan as much as 30 percent with direct impact on the infrastructure cost while improving the user experience.
Auto.Sky also handles fat client virtualization. The constant monitoring allows the platform to scale the client resources in and out reducing the average hardware wingspan of the solution layer. Cloud resources are charged on a per-hour utilization, so any hour saved on unused resources during night hours and weekends have a positive impact on the cost, which is automatically managed by Auto.Sky. Up to 60 percent of the fat client resources can be saved when using Auto.Sky compared to a simple hosting approach making this platform an optimal solution for virtualizing any ERP.
There are certainly challenges to put an original on-premise guru in the same level of hardware efficiency as a cloud-native ERP. The customer loyalty and the value of highly customized guru of a company’s existing customer base will keep these client-server ERPs extremely relevant in the market for a long time. The first step to offering a one-way ticket to the cloud is finding the right hardware wingspan so they can fly lighter in the sky.