Microsoft Dynamics NAV was born from Navision, a suite of accounting applications which Microsoft acquired in 2002.

Navision was created at Personal Computing and Consulting (PC&C A/S), a company founded in Denmark in 1983 by three college students. This company released its first accounting package, PC Plus, in 1984 (a single-user character-based application) and then in 1987 they released the first version of Navision, a character-based client/server accounting application that works over a LAN and with more simultaneous users:

In 1990, Navision 3.0 was launched. This version introduced AL, an internal application language similar to the actual Client/server Application Language (C/AL). This was a killer feature: the new application language made it possible to customize every part of the application and this was unique on the market at that time.

The product grew and in 1995 Navision Financials 1.0 was launched based on the Microsoft Windows 32-bit client/server platform:

The product was improved in the following years by adding more features as follows:

On July 11, 2002, Navision was acquired by Microsoft and Microsoft created the Microsoft Business Solutions division. In September, 2005 Microsoft re-branded the product as Microsoft Dynamics NAV.

In November 2008, Microsoft announced Microsoft Dynamics NAV 2009, with a totally new architecture, as follows:

Microsoft Dynamics NAV has had continuous improvements over the years on every aspect of its technical and functional side.

Microsoft Dynamics NAV 2013 introduced the following new features:

The next main release, Microsoft Dynamics NAV 2013 R2, introduced the following new features:

With Microsoft Dynamics NAV 2015, we saw the introduction of the following topics:

With the next release, Microsoft Dynamics NAV 2016, Microsoft introduced the following services:

The latest release (Microsoft Dynamics NAV 2017) introduced the following new features:

Now we have a complete and full-featured enterprise platform that is appreciated all over the world, able to work on-premise and on-cloud, and on many devices as shown in the following screenshot:

Before version 2009, Microsoft Dynamics NAV had a two-tier architecture.

In two-tier architectures (client/server data model), the data layers reside on the server and the application logic, presentation logic, and presentation layers reside on the client.

Starting from version 2009, Microsoft Dynamics NAV is composed of three major components (three-tier architecture), as follows:

In a production environment, you can obviously have multiple instances of each of the core NAV components:

The most common NAV architecture configurations that you can have in a real-world installation are as follows:

In addition to these three core components, there are other additional components that you can have on a NAV installation:

When using the NAV Web client, all NAV web server components are installed as a website on the Internet Information Server (IIS), so you need to install and properly configure it:

You can deploy the web server components on one computer or on separate computers (for example, Microsoft Dynamics NAV web server components installed on a server and Microsoft Dynamics NAV Server and SQL Server installed on another server). When you install Microsoft Dynamics NAV web server components, the setup adds a web server instance (virtual directory and application) on IIS for the Microsoft Dynamics NAV Web client.

Microsoft Dynamics NAV supports four methods for authenticating users who access the Microsoft Dynamics NAV Web client: Windows, UserName, NavUserPassword, and AccessControlService. Windows authentication is configured by default.

When installing the Microsoft Dynamics NAV web server components (or after installation), you can also enable Secure Sockets Layer (SSL) on the connection to the Microsoft Dynamics NAV Web client to increase security.

The following table describes the required components when using the Web client:

When activated, the NAV Web client appears as shown in the following screenshot:

As previously described, starting from Microsoft Dynamics NAV 2016, we have also native clients for mobile devices. Here is a quick view of the NAV Phone client in the following screenshot:

You can now download a native Microsoft Dynamics NAV application from the store of your mobile platform (iOS, Android, Windows):

After downloading the app from the store, you can start using Microsoft Dynamics NAV from your mobile device. You can also work with your NAV data directly from Outlook:

In Outlook, you can now also create new NAV documents:

The new three-tier architecture is multithreaded and it can handle more than one process at a time. Actually, the Microsoft Dynamics NAV server can be installed only on 64-bit operating systems and it requires a 64-bit Microsoft SQL Server version.

Regarding the NAV client, the Windows client can be installed on 32-bit or 64-bit operating systems.

If you install the NAV Windows client on a 64-bit OS, you will have two version of the client installed (32-bit and 64-bit). The default is the 64-bit Windows client, but obviously you can change it.

If you install the NAV Windows client on a 32-bit OS, you will have only the 32-bit client installed.

Microsoft Dynamics NAV also supports deployments where several different companies access a centrally maintained Microsoft Dynamics NAV application. This is called a multitenant architecture.

In a multitenant architecture, information about the Microsoft Dynamics NAV application is stored in a separate application database while data is stored in separate business databases, each of which is a tenant in your deployment.

By separating the application from the data, you can deploy the same solution to many customers with centralized maintenance of the application and isolation of each tenant.

The application database contains the tables that define an application and other NAV system tables.

Microsoft Dynamics NAV now includes Windows PowerShell cmdlets that create an application database, and other cmdlets that enable you to create and administer tenant-specific databases. You can find a complete overview of every cmdlets at https://msdn.microsoft.com/en-us/library/jj672916(v=nav.90).aspx.

The Export-NAVApplication cmdlet is the one used to extract application tables in a Microsoft Dynamics NAV database to a separate database. The new application database is created on the same SQL Server instance as the original database.

The following table describes which system tables are moved to the application database when you run this cmdlet and which tables remain in the business data database:

A NAV deployment can essentially be as follows:

With an on-premise deployment, Microsoft Dynamics ERP software is hosted at your own location on your own servers.

This type of architecture guarantees predictable performance (not subject to Internet connection related fluctuations in performance or availability), you can use the hardware and software infrastructure you already own, you can easily connect NAV with external systems that you can have inside your company, and obviously you have to guarantee data security (backup and so on) by yourself.

With on-cloud deployment, you can choose to deploy your NAV installation on the cloud by choosing from an Infrastructure as a Service (IaaS) architecture or a PaaS architecture. The Windows Azure platform permits you to have a complete NAV environment (virtual machine) totally scalable. Security is guaranteed by the Azure platform (redundancy, scalability, and so on).

Azure is the fastest and recommended way to implement a totally on-cloud NAV deployment.

The on-cloud deployment permits you to minimize your initial IT investments (no hardware costs, no IT staff for maintenance) and it supports your business as it grows (costs can scale with the actual use and needs of your solutions).

In an on-cloud deployment, you can choose to have the Microsoft SQL Server installed on a dedicated instance on an Azure virtual machine or you can use the Azure SQL database, a cloud service that permits you to have the SQL Server as a service, with reduced costs and no investments in database management tasks. With Azure SQL, you could also have a mixed deployment, where only the database tier is on the cloud.

There's also a very new option available on the market now: Microsoft Dynamics 365 for Financials (also known as Project Madeira).

Microsoft Dynamics 365 is a Software as a Service (SaaS) business proposition by Microsoft that aims to bring together the best of their CRM and ERP cloud offerings into one cloud service with specific, purpose built apps for each of your key business processes.

Microsoft Dynamics 365 for Financials is available on a simplified subscription model similar to the actual Office 365 offering and it guarantees a rapid ERP implementation (nothing to install or configure for the startup, no IT staff needed) and a familiar usage and user interface. You can work with Dynamics 365 from within Office 365 (no separate login to connect to the ERP) and you can do all your business from your familiar applications, for example, without having to leave Outlook (Dynamics 365 recognizes content such as invoice numbers inside an Outlook message and it suggests to you all the tools you need to process the document and complete your business process).

The interesting feature of this new SaaS ERP platform is that Dynamics 365 shares a Common Data Model (CDM) with Office 365. According to Microsoft's definition: it is a database of entities that are common across industry domains.

This new CMD provides all the standard business entities and it allows you to extend them and create new entities that suit your business. The CDM uses Azure technologies such as Service Fabric and Elastic SQL and it guarantees security, scalability, and consistency across applications.

The following screenshot shows an overview of the Dynamics 365 platform's architecture:

Dynamics 365 is available in the following two editions:

Dynamics 365 is licensed by the following three features:

A big new feature of Dynamics 365 will be the app concept. Users will be able to go to Microsoft's dedicated marketplace called AppSource and download a range of applications to suit their specific needs. You can reach the AppSource website at https://appsource.microsoft.com:

The new apps are built as extensions to the ERP core and they can be easily and independently deployed (you can pay for what you really need and use).

The new platform is natively integrated with Power BI and Cortana Intelligence. For example, you can install a feature from the Extension MarketPlace called Sales and Inventory Forecast and after a quick setup you can go on the item list, select an item, click the Forecast FactBox, and immediately see its sales and inventory forecast:

The connection with Cortana Intelligence is given natively by the platform (no configuration needed), as shown in the following screenshot:

Dynamics 365 is an ongoing project, and more and more features will be added in the coming months and years.

Choosing the best NAV installation architecture is not always an easy task.

The first question that an IT staff has to decide is: should I go on-premise or should I want to embrace the cloud?

Normally, the ERP is a core software component for a company and this decision can affect your business a lot.

Statistically, about 49% of IT decision makers said that they are worried about the security implications of cloud services. Data protection, privacy, and availability are the main obstacles to cloud adoption.

But is this true?

When a company stores all its core data internally, it has more or less complete control over who can access the data and data availability. An IT decision maker normally considers the company's data more secured when it is stored in a data center that he/she can completely manage and protect from the devil outside world.

This could be true in theory, but the practice is often very different. Actually, there's no company that can guarantee a service level agreement and a security policy like the cloud. Obviously, a safe backup and data protection strategy must always be guaranteed, no matter if you go on-premise or on-cloud.

There are many other aspects to consider when choosing between on-premise or cloud-based solutions, as follows:

For a successful NAV implementation, performance is an important aspect to consider and to carefully monitor.

The following are the main NAV points to check in order to have better performance:

    DECLARE @TableName varchar(255)  
 
    DECLARE TableCursor CURSOR FOR  
    SELECT table_name FROM information_schema.tables  
    WHERE table_type = 'base table'  
 
    OPEN TableCursor  
 
    FETCH NEXT FROM TableCursor INTO @TableName  
    WHILE @@FETCH_STATUS = 0  
    BEGIN  
    DBCC DBREINDEX(@TableName,' ',90)  
    FETCH NEXT FROM TableCursor INTO @TableName  
    END  
 
    CLOSE TableCursor  
 
    DEALLOCATE TableCursor 

    <add key="DataCacheSize" value="9" /> 

    <add key="MetadataProviderCacheSize" value="150" /> 

    <add key="MaxConcurrentCalls" value="40" /> 

    <add key="ClientServicesMaxConcurrentConnections" value="150" /> 

In this chapter, we have covered the NAV architecture and we took an overview of the different NAV installations (on-premise, on-cloud, SaaS), discussing the pros and cons of each.

In the second part of the chapter, we analyzed the performance problems you can have in your NAV architecture and provided tips to help you rectify them.

In the next chapter, we'll see how to open a Microsoft Dynamics NAV implementation to the outside world by using the web services native functionalities of NAV.