Last week I attended Directions North America 2018 in San Diego, CA. It was the best Directions NA I’ve ever attended. I’m not going to go over all kinds of “what’s new in the next version” because others already did, and probably better than I can. Like Waldo did on his blog (he has a good memory indeed).
Some people think there was no big news at Directions NA this year. I guess it depends from what angle you look at it. Things are currently moving in a predictable direction. Business Central gains traction, it has a focused team and it is evolving to a real cloud-first business application. No doubt partners are following it and embracing this. Over the last year we have had the opportunity to help many partners to get ready for Business Central and we see partners making the change right now.
For me, the real big change was announced a week before Directions NA. We had a MVP meeting with Microsoft in which they shared that they were really close to move completely to AL and VS Code and leave C/AL and C/SIDE behind. But we weren’t prepared for what happened during day 2 of Directions: they showed it! Apparently, they got it working over the weekend and couldn’t resist to demonstrate it during the second keynote.
BOOM!
They even updated the roadmap after the first keynote to reflect this new step that is going to happen in the future:
As you can see, the plan is to move in 2020 to AL and VS Code only and also to end support for the Windows Client. Well, the news about the Windows Client wasn’t really a surprise, but abandoning C/SIDE is really a game changer.
Surprisingly, it didn’t really get a lot of attention. During a strategic session with Marko Perisic, there ware no questions all about it (ok, until I asked to give us some more insights what this means for our future).
Huge impact
Two years ago, I already wrote about ‘the new developer experience‘. At that time I thought it was going to take 3 to 5 years for Microsoft to completely move to AL. Apparently, they are on the lower end of my estimate. Let me explain why I think this is a huge change and why you should start preparing for it right now.
We have seen quite some changes in the past that had a big impact on how we developed for Dynamics NAV. I’m sure most of you remember the move from Forms in the Classic Client to Pages in the Role Tailored Client. And what about moving from classic reports to RDLC / Word report layouts? Both changes had a huge impact on the developer ecosystem as we had to learn new technologies and tools. There were even developers who chose to not follow along and moved to a different position or completely out of the Dynamics channel. Luckily, these were only a few and the most of us are still around.
The change to AL and VS Code is not different. We will be forced to learn a new way of developing. The AL Language has for sure a lot of overlap with good old C/AL, but the way we develop is completely different. With a code editor that is used by many others, with Source Code Management in a way we could only dream of with C/SIDE. With a deployment model that is different and new possibilities like Continuous Integration and Continuous Delivery.
The change to this whole new way of developing for Business Central shouldn’t be taken lightly. Based on so many workshops I’ve delivered over the last two years, I can tell you that NAV developers are eager to learn, but it takes time to adapt and change the current way of working.
Let me share a number of thoughts about the move to AL and VS Code.
How it was done
The way how the move to AL is achieved is surprisingly easy to understand for everyone who has worked with Extensions v2. The base application, which was only delivered as C/AL objects in C/SIDE is now an app on itself. In C/SIDE you will only find some codeunits in the 2-billion range to provide platform level triggers. In Business Central October ’18 release you can already see this because Codeunit 1 was removed in favor of these new platform Codeunits.
All objects were converted to AL, which results in a big AL workspace with about 5800 objects. After compilation, which only takes about 2 minutes (compare that to a full compile in C/SIDE!) the output is an app file that can be deployed on the platform. This is the new base app.
This also means that Microsoft will use AL and VS Code as their only development environment for maintaining the base application. Which is a very good thing, in my opinion.
Modifying base app
It was made clear that we will be able to get our hands on the AL source code of this base app. Just like we can with objects in C/SIDE, we can modify the code of the base app and create our own base app.
But be careful! I consider this to be a risk! We all know that one of the beloved key features of Navision was it’s flexibility to modify code. But this key strength is also it’s weakness. There are many customers with bespoke customizations who are now stuck with an old system because upgrading became to expensive. Please follow the conversation between Guus Krabbenborg and James Crowter about this particular topic.
In my opinion, being able to modify the base app potentially introduces the old way of doing customizations. You should certainly do your utmost to stay away from that situation! Now that we have extensions technology, we should make use of that and benefit from it.
There are partners who do have a big vertical, who added thousands of objects to the base application, which can’t just be converted to an app in a week, or a month, or even a year. Those partners will benefit from this new possibility, because they will be able to turn their big vertical solution into a complete new base app and benefit from all the powerful features that come with AL and VS Code.
And then you have customers who deliberately choose to not go into the cloud. There are companies who have reasons to keep everything on-prem or privately hosted. And while you can still use AL code to deliver apps for those customers (if they are running Business Central), it is quite tempting of course to just go into the base code and make modifications right there. Although I think you shouldn’t, I would expect there will always be partners who keep doing this. Well, even those partners will need to switch to AL and apps. They will need to create there own base app, for that particular customer or group of customers.
Splitting base application into modules
A question that was asked during the strategic Q&A with Marko Perisic at Directions: are you thinking about splitting up the base app into multiple modules? And the bold and clear answer was: Yes.
Think about it for a moment: what if the base app is not one app, but consists of separate modules for Generel Ledger, Sales, Purchase, Inventory, Manufacturing, etc.? It makes so much sense!
Back to earth… the very valid question is of course: how to get there? I mean, this is like doing maintenance on a flying plane. This level of refactoring code is going to have a huge impact on everybody. Probably the new Telemetry feature it going to help here, because is allows Microsoft to see what objects and functions are used the most, and what less. But then again, I’m sure this is going to be a big change that impacts everybody!
As mentioned on this GitHub repository, you can even contribute to the modules that are separated from the base application:
Going forward, an increasing part of our application business logic will be modularized and extracted into extensions, which will be published onto this repository; this is true for both application add-ons as well as application localizations. The core application thereby becomes thinner, better extensible and better localizable. The extracted modules become open for contributions, are replaceable in the application with substitutes, serve as starting point for verticalizations of the modules or serve as samples for extension development in general.
What is unclear at this moment
There are certainly a number of issues that need to be addressed before Microsoft will switch to AL-only development. To name a few:
Data upgrade
As you may know, tables that are created as with an extension are not exactly the same as tables created with C/SIDE. The table name contains the appid and you can’t see them from C/SIDE at all. There needs to be an upgrade path to move data from ‘old’ existing tables to new ‘AL’ tables for the base application.
Migration of code
The conversion from C/AL to AL did involve a conversion tool and some manual work.
Deploying a new base app online
Another question that arises, when talking about changing the base app: will we be able to run a modified base app on the online Business Central platform? Answers from Microsoft suggest that it is going to be possible. But I’m quite sure it will come with certain requirements. For example, the base app uses .Net code while we were not able to use it with Extensions for Business Central online. Would we now all of a sudden be able to publish a base app that uses .Net code? I don’t think so… I would expect (but this is an educated guess) that modified base apps will be published on a dedicated server environment with a different price tag and you probably might need to be at a certain level in terms of users or license revenue. Time will tell…
Call to action
Let’s summarize the message into a number of actions you should take today.
Move to Extensions
If you ignored Extensions until now, then it’s about time to wake up and start moving your solutions to Extensions. With as minimal footprint in the base application as possible. Maybe you miss events in the base app, request them here: https://github.com/Microsoft/al/issues.
Learn to leverage VS Code & Source Code Management
Do not only start with moving to AL. Also learn how to use VS Code and Source Code Management and apply a strategy for working with continuous integration and continuous delivery.
Learn how to use Test Automation
Didn’t mention test automation above, but as soon as you start building apps for AppSource, you need to build automated test packages. But why not use it as a default, for both online and on-prem? It can save you so many problems and so big time…
Conclusion
Changing the base application into an app will force partners to move to AL development with VS Code. Going forward, there is no way to avoid that. Another huge change, but certainly one that brings great benefits to all partners!