The age of headless cloud ERPs
Giuseppe Maggiore, CTO Hoppinger Group
Looking at the history of bookkeeping systems, and how they evolved into modern cloud ERPs such as Microsoft Business Central, is quite fascinating. One of the very first widespread applications of computing, modern ERPs started out as MRP (Materials Requirements Planning) software in the early ’60s: they were pioneered by IBM in the context of tractors and construction machinery. After a few evolutionary improvements, the concept of an ERP (Enterprise Resource Planning) solidified around a series of core principles.
First of all, ERP software allowed accountants and financial controllers to process huge amounts of transactions quickly and without errors. Gone were the tedious clerical tasks of journaling and posting by hand (with all of the associated errors and headaches and resulting accounts out of balance): companies could trust that their financial core would be reliable and a lot of manual work could be saved. As the scope of ERPs grew, so would the number of connected departments through shared data: accounting, sales, production, shipping, and operations could all update each other in real-time, ensuring better cooperation and communication. This would, in most cases, lead to a speed up in the lead-to-cash processes: marketing would be followed up by sales as soon as possible, sales would hand over to production/operations/shipping, and accounting could send and manage invoices at a fast pace.
And the benefits would not end here: because computers are much faster than humans, the number of different accounts in the chart of accounts could grow significantly. Transactions could be “tagged” with extra information such as dimensions and posting groups, thereby gaining the ability to categorize financial, sales, and operational information much more in detail. A clear result was the ability to make informed decision with (semi) real-time data, and to improve insight into the opaque working of a company.
Of course, in the beginning ERP systems were large and expensive. This made them accessible only to large companies capable of withstanding the initial consultancy and software development impact of setting up such a complex system, adjusting it to all the specific processes, products, and services.
The rise of modern cloud ERPs such as Business Central is finally setting the record straight, and helping companies of all sizes enhance their operational quality thanks to enterprise-level support, without the huge infrastructural costs and challenges traditionally associated with it.
Customizing an ERP
Indeed, one of the biggest aspects of setting up a modern ERP is its customization. Take a Business Central installation out of the box: it can do plenty of things, ranging from bookkeeping (chart of accounts/journals/bank reconciliation/cash management), to sales and inventory management (quote/offer/invoice/shipping), and even up to project management and human resources management.
Yet, this solid foundation is no more than this: a solid foundation. The rest still needs to be built. We must create a clear definition of how to group customers and products/services (the posting groups) in order to analyze transactions and discover which combinations of customer types and product/service types are the most relevant. If we want to track even more information, such as who or where transactions have taken place, then we can use dimensions.
Dimensions and posting groups are just the tip of the iceberg of customization of an ERP such as Business Central. At some point, we want to be able to track specific information about the way a company does business. For example, a training and consultancy company might want to define schools, courses, and teachers; while a housing rental company will need to define buildings, floors, apartments, and parking spots; and so on. This way, we do not hammer everything into the ERP by (ab)using the standard tables of the system, but we define our own entities that mirror the specific business objects of the organization:
Indeed, the most exciting customization functionality comes out of the toolbox when we want to define new tables. We can now store even the most organisation-specific data into the ERP, thereby increasing the quality and richness of data related to the various financial transactions and value exchanges. The sky truly is the limit, and the goal is to ensure that all of the relevant data that needs to be stored as part of the financial operations of the company ends up into the ERP.
In the Business Central world, all of this can be achieved with AL, a lightweight programming language tailor made to build this sort of extensions.
We can thus greatly increase the precision and relevance of our data analysis thanks to more precise data, and we get less disconnected systems to work with (or, in some extreme cases, less spreadsheets “flying around” the digital office).
And with well-designed cloud solutions such as Business Central, we also get a beautiful UI/UX to work with, and to extend when needed.
Taming the MONSTER EXTENSIONS
All that glitters is not gold though. We often hear of monster extensions where an ERP was customized beyond recognition. Not only new table, but also whole operational processes and structures were pushed into the ERP together with the mountain of code that comes with it. And this is where problems start to arise.
First of all, AL is a lightweight programming language. It neither has the popularity, the libraries, nor the mindshare of “proper” programming languages such as C# or JavaScript. For example, take a look at the Google trends of 2019–2020 for C# and AL:
It is quite evident that, while AL is a powerful language, it does not enjoy the widespread adoption of C#. This means that building solutions in AL will take longer, and there will be less developers capable of doing it and less examples on how to do it. The same is true for the programming languages that are used to customize any modern ERP: they are niche languages at best.
Many suppliers have written way too much AL code (or equivalent) for their extensions. This has led to their ERPs to start taking over functionality that does not really belong in an ERP: process management, task management, we have even heard of webshops being attempted inside a modern ERP.
As extensions to an ERP become bigger and bigger, the risk that the system starts breaking down in unexpected ways grows exponentially: when extensions try and modify the system in so many ways, the risk that two unrelated custom functionalities will interact in an unexpected way, thereby leading to bugs or other issues, slowly morphs into a certainty. After all, with so much interconnected custom functionality, the number of interactions grows quadratically, and at some point developers can hardly keep it all in mind:
But wait: it gets even worse! (Promise, it gets better afterwards…) As the system gets customized further and further away from its intended use (financials and sales), at some point updates will not be compatible with your huge extension(s). You can expect the supplier of your ERP to make sure that their upgrades are compatible with their own code, but you cannot expect them to take into account the code for your humongous extensions. Typically, suppliers such as Microsoft will ensure that Business Central updates do not break rather basic extensions that features some “simple” extra tables and their list and card views, but they cannot ensure that huge processes with pages and pages of complex code will keep working “as is”. This has led to hundreds of old ERP systems on the market, that nobody dares upgrade those anymore because an upgrade would effectively require rebuilding all of the custom logic against the new version, and this would probably cost too much.
Headless ERPs to the rescue
Fortunately, we have a precious weapon: the decades old wisdom of software engineering. When tackling a large and complex problem such as digital transformation and process automation, thinking in terms of a single, magical piece of software that already does everything we need minus a bit of custom extension is naïve at best.
The proper solution is to think in terms of a software ecosystem. Multiple software components will interact with each other, a mixture of out of the box industry standard solutions accompanied by custom code for all the things that are unique to the organization.
This leads to a layered architecture. At the bottom, are the data (management) applications. The ERP and CRM play a central role here, but also the management of documents and (web) content (DMS and CMS) belong here. These systems are all powerful and customizable, but we keep them simple: adding some data definitions here and there is of course unavoidable and ensures that we can store the data we need for the organization in the right systems. Extending data definitions is powerful, adds a whole new dimension to the expressive power of an ERP (or any other system for that matters), and is completely benign: data-centered extensions usually update nicely, and contain little dangerous logic. Data extensions should also be properly connected with existing processes inside the ERP so as to enhance the ERP with extra relevant structure and information, without getting in the way with their own complexity.
On the other hand, all of the complex validation logic, product configuration logic, process management, integration with other data sources, and even complex access management and security does not belong in an ERP extension. There are better tools and programming languages to build complex logic, and you can reasonably expect that this logic will be unique to each organization and its specific business model and process. Our architectural vision is simple: take advantage of the huge power of a service bus/integration layer that implements the extra business logic and security, as well as the data integration from multiple different data sources. Modern software such as Business Central feature powerful Graph APIs such as OData, allowing external software to fetch and push most relevant information.
Finally, the whole data landscape and all of the different data management applications can be funneled into a single user experience for all sorts of more or less external end users: from franchisees and store managers, to web-shop customers. This is achieved by adding one last layer to our application, the presentation layer, that combines data from the integration layer’ own API into a uniform interaction. This interaction is not only uniform and allows access to all data, but thanks to the power of modern web technologies such as TypeScript and React, we can build fast, beautiful, engaging user experiences that further positively contribute to the effectiveness of the digital transformation.
Wait! It gets even (a little bit) better!
One last minor extra bonus: keeping the ERP clean and simple also has a positive impact on licensing. For example, ensuring that many users such as web shop customers do not need yet another paid accounts, results in far less licenses. This makes the recurring licensing costs of such an ERP lower.
Moreover, should the company decide, somewhere in the future, to move to a new ERP system, the advantages of a loosely coupled architecture are clear: most business logic sits in the integration layer, and the ERP is relatively easy to change to another system with an equivalent API.
This makes it possible for organizations to reap all the benefits of these immensely powerful modern systems, without getting tangled in a mess of expensive licenses, and vendor lock in!
Conclusion
A modern cloud ERP such as Business Central is nothing short of a hard requirement in a modern business. Real-time integration of financial, sales, and production processes will both increase quality towards operational excellence, and reduce time-to-cash.
Moreover, data integration makes it possible to perform data analyses, in order to make informed decisions with actual data.
A cloud ERP is not a standalone tool. It rather is a component in a more complex, layered architecture. Gone is the time when an ERP would be customized beyond recognition (and into expensive licenses and a deep vendor lock-in): the era has come of the headless ERP, where the ERP is interconnected with various other systems that work in concert to produce a full-blown digital transformation from the deepest back-office processes up to online web shops and customer self service.
About the author
Giuseppe Maggiore holds a PhD in Computer Science and is now currently CTO of the Hoppinger Group. He helps companies reap the benefits of digital transformations by connecting the power of high quality data and backoffice processes and software to beautiful frontoffice presentation layers built with modern web technologies.
If you like this way of thinking, and would like to get to know (or even work with!) more like-minded people, do not hesitate to get in touch with us.
