Dynamics 365 Business Central: the Impact for Partners and Developers

As you already know, Microsoft Dynamics ERP’s family is having a big evolution this year. Microsoft Dynamics NAV is now the past, while the future is called Microsoft Dynamics 365 Business Central.

The Microsoft Dynamics NAV evolution in the last years was mainly related to technology and platform aspects compared to application’s functionalities. Microsoft Dynamics NAV is recognized and appreciated in the ERP market especially because it’s totally customizable and adaptable to the customer’s business. Customizations in NAV are quick to deploy and C/AL helps a lot on this.

The big historical problem of C/AL is what some developers call “spaghetti code”: Microsoft’s code is totally accessible to you, all can be customized as you want and so it’s quite common to see NAV implementations where customized code is everywhere, unstructured and difficult to maintain.

The main cause related to this aspect is one: porting to new versions of the product requires long time, hard merging code and too much effort (costs). Many customers (with tons of heavy customizations) will prefer to “stay with the current version” instead on “going to the future”. Many companies were born during the years for helping partners and customers moving their customized solutions to a new release (Simplanova is one of them and we have already saved more than 35 200 hours of Dynamics NAV upgrade projects to our partners) but this is not always enough to increase the transition to new releases of the product.

This is the main reason why two years ago we saw the first Microsoft’s real step for moving away from CSIDE and C/AL: the extension V1. The concept behind extension V1 is simply: write a code that is isolated from the core, use events for interacting with the standard code and create “extensions” that can be installed and uninstalled without affecting the base layer.

Extensions V1 were always developed with C/AL and deployed via Powershell and they were not a big success (quite incomplete). But last year the world of NAV has changed. With Dynamics NAV 2018 we saw the introduction of the second extension’s generation (extensions V2) and the introduction of a totally new development platform (Modern Development Environment) based on Visual Studio Code and the new AL language (evolution of C/AL). This is the future. This is the development model of the current Dynamics 365 Business Central platform (on-premise and SaaS) and it will be the only development platform available from the year 2020.

 

Microsoft Dynamics 365 Business Central Roadmap

 

Dynamics 365 Business Central Roadmap

Dynamics 365 Business Central Roadmap

The Microsoft’s roadmap now is very clear and was publicly announced at Directions North America 2018:

  • Start forgetting CSIDE and C/AL (From the Year 2020 – VS Code and AL will be the only way to modify the application.);
  • Start forgetting Windows Client and become familiar with the Web Client;
  • Start thinking on moving your solutions to extensions;
  • Start becoming familiar with Visual Studio Code and the AL language;

This is probably the last year with C/AL and CSIDE and this is the main impact for all the NAV partner ecosystem. Microsoft has clearly said, that this in the last public event, when they’re ready for the jump (Microsoft has shown a full Dynamics 365 Business Central solution where the base application is now an entire extension and only some system objects are still in CSIDE) and for the future Dynamics 365 Business Central releases you will have no more side by side development, but you will have only AL and extensions.

Microsoft and its communities of MVP’s have started from lots of time a big “evangelism” campaign on helping customers on this jump but the process is only at it’s initial stage at the moment.

 

Directions EMEA 2018 – a Must Visit Conference of the Year

 

As you know, at the end of this month we’ll have Directions EMEA 2018, where Simplanova will be the silver sponsor.  This is a conference “not to miss” this year. We suggest you to be in Holland if possible and start to prepare your mind for the jump to the new era of the Microsoft’s ERP.

There are key topics that a “2.0 Microsoft ERP solution developer” must know today:

  • AL development
  • Docker
  • Source Control
  • Azure Cloud ecosystem
  • Integration aspects (web services, APIs)
  • SaaS vs On-premise aspects
  • CDS and Dynamics 365 family overview

Directions EMEA is a great opportunity to know more about all these topics and to be prepared for the future. Here you will have opportunities to speak with Microsoft teams, to speak with MVP’s and to share ideas and questions with all the Microsoft Dynamics partner community of EMEA region.

 

How to Move Extensions?

 

Moving to the extension’s technology is not a simple task for a NAV partner. The difficulties are not only related to code topics, but they also involve a complete shift of mind for the partner’s organization.

Actually, the traditional NAV partner workflow is what we call “quick responsive”. A customer ASKS and the NAV partner DOES the task in very few times with only this customer in mind. Often, the partner starts a project from it’s internal model database and then this environment is soon forked for every customer. At the end of this process, for N customers, a partner will have N different environments with different customizations that will be always managed as completely different platforms.

The extension model does not suit well with this model.

With the new development model, you cannot think to fork your extensions for every customer you have. You have to re-architect your solution, not simply convert it to a new language. You cannot think that taking your actual C/AL solution and convert it to AL (manually or with tools like Txt2AL) will give you a well constructed and full working new solution. And you cannot think that if customer A asks for a customization, you can immediately complete the request without a more careful analysis of the impact of this request.

What normally we suggest to partners who start moving their ISV C/AL solutions to AL, is to absolutely avoid having an extension that is forked (customized) directly for every customer. If you have moved your solution to the extension model and now you have a base extension (EXT BASE), the biggest error that you can do (and we see this today when you have Customers 1,2,…,N) is to directly modify this extension’s code for every specific customer:

How to move ISV C/AL solution to AL

How to move ISV C/AL solution to AL

This is the “C/AL mindset” way of work. I have a general code, then for Customer 1 I take my general code and I customize it as needed. Then I have Customer 2 and I take my general code and I customize it as needed for Customer 2 and so on. At the end, every customer will have it’s own implementation and you will have to maintain N different extensions. That’s too bad and it does not suit well with the new development model.

You should think with the target to maintain a base extension (your base solution) and on top of that you will create “customization layers” for customers:

How to to maintain a base extension with customization layers

How to to maintain a base extension with customization layers

This is a must! In this way, your core application (base app) can be centralized and maintained by a dedicated team. Then, the teams that work with the customers, can start from that base app and create customizations that will be dependent extensions from the base app. Obviously, to reach this goal, you need to extensively use events in your base extension (Integration events). In this way you’ll have a solution, that can scale and suits well with the new development model.

This is not simple, but a goal to achieve nowadays.

To be proficient with the new Modern Development, source control, test automation and continuous delivery / continuous deployment, these topics are the main you will have to master in the nearest future (when working with large AL projects in team, you will soon discover problems on managing .al files and if you’re out of source control, you will have troubles for sure). In the upcoming Directions EMEA 2018 there will be some sessions about that.

As source control platform, Azure DevOps is more preferable than GitHub (it’s more powerful if you work in team in a company), but obviously, this is our personal choice. Azure DevOps has Pipelines, Boards where teams can track work items, issues or bugs, Repos (unlimited private or public Git repositories), Test Plans for managing automated testing and so on. All in a centralized and beautiful environment:

Azure DevOps

Azure DevOps

The key point here is that you need to have source control in place absolutely.

 

Integration

 

Another topic you need to master in the upcoming year is Integration. The is a great blog post in Stefano Demiliani blog regarding the common integration technologies we see every day on NAV projects here and we think you should start avoiding direct SQL integrations (in the cloud a solution like this will not be portable) and file-based integrations. The new topic to master is APIs and Web Service. Using these technologies as a part of your external integrations with Dynamics 365 Business Central will permit you to have a solution that works on-premise and on-cloud, scalable and totally abstracted from the database.

 

Are your Customers Ready for the Transition to Cloud?

 

Not all of them are ready for this shift, especially in the ERP field. The ERP is always seen as a core business application and customers often want the on-premise version, at least to start. As you already know, Dynamics 365 Business Central is available on-premise from October 1st 2018 and if you have a customer, who wants Dynamics 365 Business Central now, don’t direct it to the cloud immediately by forcing his mind if he doesn’t want this.

The cloud jump is something that could be a “step 2” of a project, if needed. If you’re in this situation, start on-premise with extensions and then be ready for a possible cloud transition.

Microsoft knows that and they’re working on helping for this transition. You can work on-premise and just now use cloud features to improve your business. Microsoft for example provides the Intelligent Cloud Insight in Dynamics 365 Business Central where you can “synch” your data to the cloud and then leverage the benefits of feature such as AI:

Intelligent Cloud Insight in Dynamics 365 Business Central

Intelligent Cloud Insight in Dynamics 365 Business Central

As you can see, there are a lot of changes. This is a hard moment, when you have to review your organization development and solutions, but this is a step that must be done. From Microsoft side with the base app and from your side with your company solutions.

Dynamics 365 Business Central might loose those easy and quick modification features that actually the old NAV has, but it will become a modern platform, ready for the cloud and for the future of all the entire Microsoft’s ecosystem.

We are waiting to see you in Holland at Directions EMEA 2018 at the end of this month. We would be happy to talk about these topics with all of you and help on taking the right road for your future projects. Visit Simplanova booth N16, talk to our team about migrating your existing solutions to Dynamics 365 Business Central, add-on upgrades to extensions or extension training courses for your team.

Do not miss our session on Monday, October 29, 2018, from: 13:30:00 to 14:15:00 at room: OCEANIA F on the topic Dynamics 365 Business Central Upgrade Strategies, MS Incentives and Automation Tools. More information here.