Beyond ERP Development – Integrated Platforms & Programming

Dusan Jugovic, Senior Systems Engineer (Partner at Codeeco)

September 5, 2018

Developing ERP applications is not something that I had in mind when I started my undergraduate studies in university.  During my third year in the Faculty of Science, I was offered an opportunity to join a programming team responsible for refactoring an ERP product for one of the leading IT companies in Southeast Europe.  I guess you could say that this was a new ERP version that would impact the ERP domain of integrated business solutions.  At that point of their company history, they were promoting a 2-tier ERP system developed in Delphy and backed up by a number of experienced ERP consultants.  This was the main product of their company, and their “bread and butter” so to speak.  It was implemented in some of the largest companies in Europe.  At the same time, big clients showed up and were excited to invest in new ERP system development.  As the technology was moving forward at a rapid pace, the logical step was to evolve to a 3-tier successor, in this case built on EJB 2.0 technology (CMP Entity Beans).  And the rest is history as they say.

History doesn’t pass by without its challenges, especially when technology is at stake and companies are expected to out-do their competitors and grab market share.  In the case of ERP, companies had to figure out how to implement and deploy ERP systems while upgrading them as technology advanced.  However, companies soon realized the problems with EJB 2.0, and had to find a workaround by incorporating lightweight persistence.  It wasn’t until the migration from EJB 2.0 to EJB 3.0 that the persistence problem was resolved, but at that point our tech stack had moved on and we didn’t want to go back.  Furthermore, there was the problem of enabling multiple database support and having a reliable custom persistence manager.  Management had no way of anticipating these problems mainly because they weren’t technical.  And their IT guys didn’t have the experience with ERP and continuous technology enhancements.

It wasn’t long before a very development-savvy colleague from university joined our illustrious team.  While ERP was going forward, other applications were needed to augment this beast, and our knowledge needed to be upgraded with all the other upgrades that were going on.  For that reason, we started to work on smaller private projects where we could experiment with new technologies and prove the concepts.  A proof-of-concept was the only way to convince all the business and IT stakeholders.  After working on project that created 3+ million lines of code, everything else was a piece of cake. 

At this point of the ERP history timeline, we had a monolithic 3-tier desktop application that needed to go to web if we were to survive as an innovative programming team.  Back-end Java-based architecture proved itself as a steady ground to build upon.  By updating it from version 1.4 to Java 8, we were able to always maintain system stability with a certain amount of code refactoring.  Management’s decision was to go with Google’s GWT.  They were aware of the fact that we had to entertain dynamic and reusable UI components, and write client code in the same language as the server was at the core and supported an integrated technology landscape.  We went one giant step further and introduced Hibernate to simplify data persistence.  We conceived a technology framework and provided technical resources to support the transformation.  As Google says: “Productivity for developers, performance for users”.  Who can argue with that logic?

The Road to an Integration Technology Platform

The domain knowledge that we acquired working on these projects was priceless, but developing only within the ERP domain was just the beginning.  Thus, we analyzed current technology trends and searched for something entirely opposite to the things we were working on at that point.  And we found it!  Ladies and gentlemen, may I introduce SWIFT – Apple’s new programming language which was recently released to make it easier.  SWIFT is exactly what it says it is – a better and faster way to deploy technology solutions.  SWIFT, although not a core technology tied to ERPs, has proven to be a great development environment for mobile.  So, we started developing iOS apps, and continued our work on ERP as experts in the field.  We even formed our own company that said, “We are the guys who can develop and deploy your ERP solutions with great success”.  I don’t mean to be arrogant about our technical capabilities, but we have more experience than most companies, and a team of ERP analysts and programmers that live and breathe this stuff.  I admit that our consulting company is continuously looking for competent developers to fulfill specific resourcing requirements on a project basis, and after several successful ERP deployments, we have formed a stable team with a wide range of skills and talents – including those required for Digital Transformation.  Digital Transformation is one of those make or break technology platform deals.  If you don’t do it right, you won’t get another chance and you may as well close shop.  In our case, our shop just got a bit bigger as we have rebranded ourselves as the Digital Transformation experts. 

As the number of clients and applications grew, it was obvious that a new organizational structure was needed.  Our clients demanded one integrated technology platform from which all applications are managed.  Thus, we jumped on the Beyond Business Suite bandwagon, which was later transformed to Beyond Digital Platform.  The biggest benefits of an integrated technology platform includes the following:

• • Identity – one access point for all users
  • Integration – capability to connect different technologies
  • Simplicity – basic, common building blocks for all modules

The following diagram illustrates the various components which comprise the integration technology platform called Beyond Digital Platform.

The Beyond Digital Platform was the first step towards a formal and real Service-Oriented Architecture (SOA).  Since SOA is a term that is passé, let’s just call it an integrated technology model that supports service provisioning.  For those architects who dwell on open source technology, this is an Open Architecture framework which supports Digital Transformation services with a complete technology stack as illustrated in the model above.

The Big Guns: Angular and React

While there are numerous options for web technology, we have made it our mandate to work with robust and proven technologies.  In the beginning, it was a toss-up between React and Angular – two leading JavaScript technologies for single page application (SPA) development.  Both of these development environments are very popular, and even more appreciated.  Before React was introduced, AngularJS was the leading and probably the only true SPA solution.  It provided client-server side MVC architecture, two-way data binding, templates, and dependency injection in one framework.  And then in 2013 React was introduced, a JavaScript library for building user interfaces.  The following years, React became noticed and gradually gained a reputation.  By the end of 2016, React went mainstream.  At the same time as the landscape of web development changed, AngularJS had fallen behind.  So, in 2014, they announced Angular 2.0, a new framework built from scratch which in fact was a total rewrite.  From a developers perspective, that meant that all the time they invested was a waste and their code had to be replaced.  It wasn’t until 2016 that Angular 2.0 was officially released, and in that time, React took a stronghold in the market.  Although React was gaining more popularity, Angular managed to stabilize its framework and regain developers confidence.

From the perspective of our consulting practice, Angular seemed to be a better fit.  Firstly, as mentioned before, React is a library which provides great flexibility in terms of application architecture.  However, too much flexibility in developing ERP solutions can be a burden.  On the other hand, Angular as a framework provides some nice defaults like network connectivity, state management, language choice, building toolchains, among others.  Furthermore, Angular has better documentation, a more strict but extensive rules engine, and all of that, in general, allows better productivity for enterprise applications.  On the backend, we used Java and exposed REST API’s, and in combination with Angular, it worked like a charm.

As you can see, managing an ERP environment is not as easy as vendors may let you believe.  It’s easy to show PowerPoint slides, but a different matter when it comes to actually building and maintaining and ERP environment.  In order to be successful, you need expert developers with the right tools, and this usually comes in the form of an integrated technology platform with customization using various programming languages.  It was the intent of this article to give you a taste of what you’re getting into if considering an ERP for your organization.