Performance Challenges in Cloud-based ERP Software
By Erik Damgaard, CEO Uniconta
Using a Cloud-based business and financial management system has many benefits for any type of organisation. However, it places completely different demands on the software provider, assuming responsibility for the underlying infrastructure. And that is no trivial task.
The spring of 1991 was the first time I experienced in earnest that financial management, accounting and business systems, now called ERP (Enterprise Resource Planning), are exposed to particular challenges with performance.
At that time, we had just launched Concorde XAL, which we designed for medium-sized companies when the first reports of problems came in from some customers.
In certain situations, their system ran slowly and sometimes it came to a complete standstill.
For this type of customer, who had taken Concorde XAL into production, the problem was critical. If they could not book orders, invoice customers, and pay suppliers, it could have severe consequences for their ability to meet their obligations.
When we had not experienced this type of problem with Danmax (our first product that came in 1984) and Concorde Economy (a multi-user system we launched in 1986), it was primarily due to two factors:
- The customers were mainly small companies, where only a few employees had to perform financial tasks simultaneously.
- The systems were elementary with limited functionality.
With the launch of Concorde XAL, we gained larger customers, where many concurrent users had to perform far more complicated jobs simultaneously.
It made completely different demands on the architecture of the software.
Performance is a well-known problem
A transaction in an ERP system affects many data elements.
When a user completed an invoice, the ERP system initiated a large number of operations and wrote system messages on the screen:
“Processing item number XXXX”…
“Adding sales tax”…
“Updating debtor”…
“Updating general ledger transactions “…
“Updating accounts receivables “…
“Creating inventory transactions”…
“Invoice completed”…
Thus, creating an accounts receivable invoice must access and update many tables in the file system before it can be completed. Accounting daybooks can contain hundreds of transactions, all of which must access the same tables. The more features the system offers, the more tables will potentially need to be updated.
To ensure ACID (Atomicity, Consistency, Isolation, and Durability), the database needs to lock the tables until the system can complete the transaction in its entirety. For the sake of Recovery (in the event of a power failure, for example), the database also has to wait to confirm the entire transaction until the update of all tables is ready, verified and committed.
If you do not design the software to cope with these conditions, performance problems will quickly arise, and they can only be solved here and now with more and faster hardware. That means faster CPUs, more central memory and faster data storage. It was in the 1990s, and is funnily enough to this day, an expensive solution.
The performance issues we experienced in the early 1990s arose mainly on installations using Unix computers from Digital Equipment Corporation (DEC), with whom we had a marketing agreement.
It turned out that the file management system in the operating system, ULTRIX, was not suitable for running administrative software. Although DEC was the world’s second-largest IT company, they could not solve the problem without rewriting their operating system. It was not a task they would take on just because a few customers in Denmark had issues. Instead, DEC’s Danish subsidiary chose to either set up more powerful computers or move the customer to a PC platform.
At that time, DEC first solved the problem when we released a version of Concorde XAL that used Oracle’s database system, which completely bypassed ULTRIX’s file system.
Cloud and SaaS just make the challenge even greater
When the ERP system is delivered from the Cloud in the Software-as-a-Service format, the performance challenge becomes many times greater if the potential bottlenecks are not taken into account from the start.
If you want to deliver a business system from the Cloud at a competitive price and with a reasonable contribution margin, the solution must be multi-tenant. It means that all customers must run the same version of the software and use the same database. The alternative, where each customer runs on a separate instance and database, will require a disproportionate amount of computer resources and be expensive to maintain.
Imagine that you had 5,000 customers ten years ago, each with between one and a hundred users (a total of 25,000 users). They ran their ERP system on individual servers (one or more) and optimised their systems according to their needs and workload.
In the Cloud, all 25,000 users now run on the same system, and it is your job to ensure that they can perform their tasks as best suits them without experiencing slow response and the blue circle of death. Also, when at the end of the month, they all send bursts of daybooks against the system while their colleagues update the bill of materials and inventory lists.
Where the customer’s PCs ten years ago connected to the servers via fast local area networks, a cloud solution today depends on the quality of Internet connections. Even with fast Internet connections, the communication channel between the user’s PC and the system in the Cloud remains a critical bottleneck. I am convinced that users of other systems have experienced this during the Corona pandemic, where they suddenly had to work from home.
In summary, one can safely conclude that it is technically much more complex to deliver an ERP system from the Cloud than if the system could continue to run on the customer’s computer. When something becomes simpler and more convenient for the customers, then it is because the supplier takes over and performs more of what is complicated.
Uniconta and performance
Although Uniconta initially aimed to offer an alternative to companies using Microsoft Dynamics C5 and other, older ERP-systems, I was aware from the start that we would experience precisely the same development in demand as we did in the 1990s. Larger and larger companies would be interested in Uniconta because we could offer more and more functionality, more customisation options, more standard integrations to other systems and not least a large crowd of resellers deeply specialised in different industries.
Therefore, I was already very aware of the whole performance issue when we made the first design specifications for Uniconta.
Uniconta is both an App and a Cloud solution
Unlike virtually all other cloud-based ERP systems, Uniconta is an App on the user side. It means that much of the user’s activity takes place locally on her PC.
In addition to the fact that the App can be designed to be more user-friendly, it also utilises the PC’s resources. It does not have to continually send and retrieve screen layouts and system information to and from the Cloud.
RAM is always faster than external storage
While a user prepares her transaction in the Uniconta App, the system searches in the background for available data blocks in the PC’s central memory. Windows is not so good at quickly releasing free memory, and in a standard setup, it forces the application to write all or part of the transaction to the external storage.
Although many PCs have now replaced mechanical hard drives with the much faster solid-state drive (SSD), it is still and will always be much quicker to access data in the central memory.
In other words, Uniconta can spot available data blocks in the central memory before Windows does, thus speeding up the process. Mostly, the entire transaction will therefore be in the central memory when the user is ready to send it off to the part of Uniconta that runs in the Cloud.
Several small queues are better than a single long one
When you send an email to 10 people, does Outlook then write:
“Sends to Per”…
“Sends to Poul”…
“Sends to Kirsten”…?
No, it doesn’t. Because Office365 does not send your emails as soon as you press send.
First, the system checks if all email addresses are valid, and if they are, the Office365 server receives your job and queues it.
Now your Outlook is free, and you can continue working on writing new emails, creating tasks and booking meetings.
In the background, the Office365 server sends your email to Per, Poul, Kirsten etc.
We have built Uniconta according to the same principles.
When you press “update invoice”, we check that all items are in stock, that the debtor does not exceed his credit maximum, that the period is open, etc.
Once everything has been checked, the user gets an OK and can now continue working.
In the background, the Uniconta server updates the invoice in all the relevant tables and sends it via email or oioubl (official data exchange standard).
However, if the Uniconta server is busy updating another invoice, it will queue your invoice and only raise the bar when the path is clear.
It means that even when Uniconta receives 1,000 invoices simultaneously, it will not try to update them at the same time, as it is guaranteed to create deadlocks in the database.
As traffic intensity increases, Uniconta simply creates more queues.
It corresponds to the principles of a Danish ferry berth. Here, all the cars get marched up in many rows instead of just waiting in a single line. Trucks and buses line up separately because they have to enter through a different gate than the cars. When the ferry arrives, it can be emptied and filled in less than a quarter of an hour.
Similarly, Uniconta distributes users’ transactions in many queues and settles them when and where there is available capacity.
Uniconta’s queuing system means that the database’s locking of tables in the transaction process does not cause the traffic to accumulate, which would require more and more system resources to handle the settlements. Where database software is eminent for ensuring integrity (ACID), it doesn’t always address congestion well. When this happens, the system turns on the blue circle of death, and the user has to wait for the next open slot. It does not occur in Uniconta because the user’s App is released when the transaction is sent, and our queuing system takes over.
The Cloud has many benefits, but under the bonnet, the technique is not that simple
When companies have embraced IT in the Cloud, it is because the benefits are so obvious.
- They avoid investing in and maintaining a complex IT infrastructure that is subject to rapid technological obsolescence.
- You do not have to worry about updating the software.
- They do not need staff for support and backup.
- They do not have to worry about the security of the central systems.
- They can add users as needed without having to invest in more software and server capacity.
- They can remove users and achieve an immediate cost reduction.
- They gain access to solutions pre-integrated with the many other systems to be used across the organisation.
In the same way that most companies do not invest in and operate their own power plant, IT operation is not a core competence on which they want to spend time and resources. Therefore, IT delivered from the Cloud is a welcome method to access advanced solutions easily.
But IT delivered from the Cloud simply means that the software supplier takes over responsibility for the central systems. Therefore, the quality of the user experience depends on the extent to which he (or she) is a specialist in everything that lies under the bonnet.
The developers behind Uniconta have been working with ERP software for almost 30 years, and there are not many situations and issues we have not seen before. We have designed Uniconta from scratch as a multi-tenant ERP system in the Cloud, which must serve both small and large customers even if their IT behaviour is very different.
With Uniconta, you experience a fast response and avoid the blue circle of death.
Erik Damgaard, CEO Uniconta A/S