Dynamics Nav/Business Central

Development Environment

Live of a business central developer.

Live had been good for us at our company. On the turn of the century we had a software package for Retail Fashion Stores, build in ‘C’ and running in a character based environment under Unix for multi-user and DOS for single user environments. The company started this product early in the eighties and it had grown to a fully-fledged software package for retailers. We had many satisfied customers. It contained it’s inhouse database system as many had who started development in the early eighties, super-fast and compact.

We were overdue in our change to the windows environment. All kind of reasons can be found why, such as ‘the customer is not asking for this’, ‘text based is much faster than clicking around’ and who is going to win ‘windows or OS/2’. But eventually, when the market switched to windows, we were behind.

Reflecting on this, we decided to switch too. Instead of developing everything in house, our attention was drawn on an environment which contained base functionality and on which we could extend with our knowledge of fashion retail. Navision was the name. Development of the first version took some time but it was not as much as we expected. Our first customers were converted within  2 years.

A few years after we started, Microsoft had acquired Navision, and the name changed to Dynamics Nav.

We decided for the development of a integrated retail-addon. After we ported our existing functionality, we extended it further. In the next 20 years or so, it became a massive add-on, being larger in number of lines of code, than the base Nav version.

For many years Nav was quite stable from a development point of view. Up to Nav 2009R2 not much disrupting changes where made to the product. And then Nav 2013 came… reports gone, RDLC reports in place. It took lots of work converting all reports in our add-on to RDLC. Pages replaced Forms,  dataports where merged into the XML ports, so we got an XMLport that could output CSV files 😉.

As a small company we managed the change. But change was not over, not by far.

The C/Side development environment gave us access to the Microsoft codebase. It allowed us the change it as we saw fit.  And so we did. Adopting new versions of the Microsoft became more work over time due to the changes we made.

‘Events’ to the rescue.

The eventing system introduced in Nav is great for solving the spaghetti code problem where partner code is placed al over the base Microsoft code. But, many code rewrites where needed to adhere to this new paradigm.

And now AL is there. It’s a mayor overhaul of the development environment. Developing is not done in the product anymore. No,  we now have ‘source files’ and an IDE. We compile, and a deployment package is generated. De development environment is visual studio code. Sources can be managed in source control, GIT can be used with all it’s possibilities. The Nav product is meanwhile renamed to Business Central, and with the new development environment, is ready for the future.

But we are not there yet. Our massive add-on needs to split in loosely coupled extensions, a devops development street needs to be setup. ALOps seems the way to go… So lets see what the future brings.