Did I know before I started Acumatica that we needed to build a platform? The answer is yes.
But though I instinctively knew ERP products needed a development platform as a foundation, through the different stages of my career, I had a different vision about why the ERP product required a development platform.
In the mid-1990s, I was an application developer in a role that introduced me to the ERP development platform. In those days, my view was very straightforward. Platform must simplify my life and eliminate as much code from the business logic as possible. I saw things through the lens of programmer efficiency and was never happy with the system team and cumbersome development platform we used at that time.
One thing I learned, though, was the value of the code unification. It is nice when all code related to the business logic is located in a single place. Platform restrictions forced programmers to write the code in similar paradigms, to allow for easy reading and maintenance.
By the end of the 1990s, I had made the switch to consultant, implementing the ERP products for end users. Instead of caring about ease of writing and maintaining the code, I was more concerned about the end user now. That posed a totally different scope of actions: Is the product stable? Does it matter how easy it is to develop new screens if it crashes every 10 minutes? Can it be easily modified for user? How will upgrades affect customizations? Will users lose maintenance revenue if they cannot upgrade products because of customization?
I knew then what the ideal ERP development platform included: The developed product should be super stable, customizable, and upgradable. And these priorities should probably precede the ease of development.
My next ERP platform worldview change occurred when I joined Parallels as Director of Engineering, where I was introduced to interactive internet applications. Back in 2004, not many people thought about building an ERP application in the browser.
For me, that was the moment of clarity. I was finally able to meld my past ERP experience with the new future technologies. I combined all I understood about platform ERP — ease of use, code unification, customization, runtime stability, upgradability — with the vision of technological superiority provided by a platform.
That’s how Acumatica was born.
I spent the next crazy years building the prototype, getting investors, and convincing them that they had to wait till the platform was ready. Imagine an ERP application written from scratch: 1 million lines of business code. Tested. Deployed. Fixed.
From the first version release to where we are today with Acumatica 4.0, I’ve drawn on my experience as a project manager, technologist, programmer, consultant, and support engineer.
Having seen the value of a platform from all these perspectives, I have realized that all these priorities listed before can be thrown out the window if platform does not isolate your business logic from the technology and make the code responsible for the business logic immutable over time.
Why? Because in those seven years spent architecting the product, technology has leapfrogged.
We’ve seen HTML, ADO.NET, and asp.net turn into HTML5+JS, Linq and MVC. And it is going to change again and again and again.
Can you imagine what would have happened if we had chosen to use one of these latest technologies in the market at the time and wrote our business logic using it as is? We would have had to constantly go back to our application code and re-work it to reflect the technology changes. It would have become physically impossible to release a stable product when you have 1 million lines of code in need of constant modification.
Building on the “new” technology of the moment often means you are left fixing your code when the “new new” technology emerges. Building an ERP development platform without isolating your application code from the technologies makes all other platform advantages obsolete in a very short period of time.
In Acumatica, we’ve put an extra effort to build this isolation, and it’s really the best protection of our investments into the ERP product development. In my next posts, I’m going to explain some of the technologies and approaches we’ve used for that.