As you might have heard, Microsoft Dynamics NAV has a new General Manager: Erik Tiden.
He got a great online welcome via Waldo's blog. Well, not a welcome, but a clear message he has some big shoes to fill.
Last wednesday during speakers dinner for NavTechDays 2012 I had the pleasure of sitting next to Erik and and got the chance to know him a little better. We talked about SAP where he has worked earlier and Dynamics NAV. I also introduced to him what the MVP program was all about, although not in a conventional way.
Erik can be described as a "Swedish German" who now lives in Denmark. This is not a bad combination for someone to lead NAV.
With just three weeks on the job, NavTechDays was clearly a great way of introducing the community to him. I can only imagine it as trying to swim in the deep without diploma.
He has the priviledge to announce the great release of Dynamics NAV 2013 which he did during the keynotes.
I wish Erik a great time at his new position and expect great things.
You can watch Erik do the keynotes here.
With kind regards,
--- Erik's new Dutch friend --
Ok, let's go back to what matters. The cool stuff about NAV 2013.
At NavTechDays Antwerp I did a deep dive into the changes that are made in Dimensions. In the comming blogs I am going to share this.
What are dimensions
Dimensions are first introduced in version 3 as a replacement for project and department codes and have two main functional purposes. The first is restriction checks on posting. We can for example give a G/L account a mandatory product dimension or vice versa block a certain dimension or dimension value for posting. The second purpose of dimensions is data analysis. Using dimensions allows us to define analysis views that we can use for reporting and analysis.
The main elements in Dimensions are Master Data, Journal and Document registration, posting and analysis.
Problems & Challenges
Let’s look at the problems and challenges we have with Dimensions and the reasons for the redesigned in NAV7.
Storage Firstly we have the storage issue. Dimensions can consume up to 33% of the space in a database.
Performance Moving the data through the database takes a cut out of the performance. This is at least 30 % even if you don’t use dimensions.
Coding I think many developers here agree, to take dimensions into account when posting a journal or document you need quite a substantial piece of coding.
Let’s compare the design pattern in NAV 6 or earlier and NAV 7.
If we look at the first part, master data, we can see that there are almost no changes in the masterdata part of dimensions. A special one in this list is the Job Task Line dimensions. Microsoft considers this table master data, also because you can assign multiple dimensions.
The biggest change is in the way dimensions are assigned to journals in documents. All the tables that are designed for this in previous versions have been replaced by one new table Dimension Set Entry. In this table NAV stores all used dimension combinations. Rather than storing all separate dimensions for each record, each record is assigned to a unique set combination.
This allows us to do what I personally consider the nicest change in this new architecture, to move the dimensions through the posting routines, all you need to do is assign the correct Dimension Set ID.
To analyse the data, codeunit 410 has been changed. This codeunit has always been a bottleneck in Dynamics NAV for performance reasons. In Dynamics NAV 7 this is based on the new query object.
The Dimension Set is the biggest change in NAV 7.
Each table that contains dimension information should contain a new field Dimension Set ID. In the core product this is always field 480.
Calculating the SET ID is done in codeunit 408.
This codeunit is also been on a huge diet. Because there is no longer need for the data moving functions 50% of this codeunit has been removed. Perhaps even more because the new code for the Set handling has been added.
Each table should have a new function for showing the dimensions. This is done using the dimension set entry table as a temporary table.
-- To Be Continued ---
Ok, so if you've landed on this page, I asume that you have read my previous two blog posts about Azure and CfMD. If not, please do so, since it will clarify the reason of this post.
Microsoft annouced earlier this year that all of its ERP product will be cloud enabled in the next major release.
And they did. It works.
Or no... they did not, it does not work as they prommised it would work. Microsoft also promissed it would be Multi-Tenacy.
"The next major releases of Dynamics AX, GP, NAV and SL will be developed to run on Windows Azure, Microsoft's cloud development platform that's been available for a year, Tatarinov said, beginning with the next version of Dynamics NAV that's due in 2012. The applications will support multi-tenancy, he said."
So I confused you. I did, didn't I. Well, I would be confused if these terms were unfamiliar. So let's talk about these terms and hopefully you understand what I mean and the difference in impact for Dynamics NAV customers and partners.
Cloud vs. Azure
Ok, so I asume that you all heard about the cloud. This "thing" that replaces your local hard drives and allows you so save data "somewhere" and use application without them residing on your system. This is the cloud as it is offered by Google, Amazon and loads of other smaller and local it infrastructure businesses.
In the cloud you can also "rent" a virtual machine. This is an online alternative for buying a server and install it localy in your office. You get the same functionality without the hassle of the physical machine.
Microsoft also offers this on Azure. Or so they will since it seems not to be released yet.
But Azure is more than just a Virtual Machine on the internet. Azure is an amazing technology about scalability.
I heard about Azure and its possibilities first when I visited TechDays Sweden some years ago with Waldo. Azure allows you to run online services that have their own communication protocols and scalability technology.
This is based on webroles and workerroles.
The webrole listens to the user requests that are processed by workerroles. The cool thing about this and what makes it different from normal windows services is that they scale automatically.
The most commonly used example about azure by Microsoft is a ticketing system. Let's say for example an event like NavTechDays starts selling tickets tomorrow morning at 8am. We have 600 tickets available. We expect them to be sold out within one hour. In a normal situation we would need to install hardware that can handle this level of requests just for one hour. Azure will handle this for you and scale out when nessesairy and slow down when not needed. You only pay for what you need and you don't worry about the HW.
Ok, so that was an extreme crash course on Azure. Now let's talk Multi Tenacy. This is what Wiki says:
"Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants). Multitenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations. With a multitenant architecture, a software application is designed to virtually partition its data and configuration, and each client organization works with a customized virtual application instance."
Reading this definition hopefully explains why the entire ERP world suddenly started to watch the next release of Dynamics NAV. In NAV words this means running more than one customer on one solution and one database.
Having read my previous article about CfMD and listening to our PRS presentations, this is definately not something that the NAV partners are ready for. AT ALL!!
Imagine, just imagine, what this would do from a repeatability viewpoint. Allowing a customer to just hop on in an existing infrastructure environment. No installation, no discussion about customisations. However this means that the application must be solid and reusable.
No doubt the opportunities of a technology like this is gigantic. Customers who nowadays cannot afford an ERP solution like NAV because of infrastructure and implementation costs are suddenly potential buyers.
So what do we have in NAV 2013?
NAV 2013 is, just like NAV2009R2, completely cloud enabled, meaning you can run it on a hosted solution outside of your active directory (Which is something you don't have in the cloud).
In NAV2013 we also have a great WebClient that makes it even easier to run NAV in the cloud and you can use Google ID for example to authenticate. We also have the possibilty to use the good old NAV Users like we had in the classic client.
Azure & Multi-Tenacy
This is something we did not get (yet I hope).
However, even if we did, I doubt that NAV partners are ready for it. With so many registered "solutions" I doubt that partners are ready for repeatable solutions.
I should have known better, but I was naive. My very short blog post was blown up within a day and all over the internet. It does not contain any secrets but in my opinion it definately needed clarifying.
Hopefully this blog post did. I'm looking forward to a bright repeatable future and trust that partners after this are more prepared for it than ever.
For some of you the Azure post yesterday might have come as a surprise, as my dissappointment.
About a year ago, we (the PRS team) started to evangalise about repeatablilty. This was one of the main pilars of our story about programming "nicely".
For years, or almost decades, Navision and later Microsoft have struggled with the repeatability story and making the ISV/VAR story a success.
When I started with Navision they introduced the idea of Add-Ons and verticalisation. The idea is that rather than having NAV partners compete with each other, have them be specialist at some area of industry. This worked like a charm when it started in the late 90's. Everyone was busy and had more than enough customers, so if someone approach you asking for a certain solution, rather than developing it as customisations, you'ld point them to another partner and vice versa. This is how I rolled into the Transportation business where I still am active today.
But somewhere after this it stoped working, or something else happened, I don't know. The unofficial numbers of "vertical" solutions registered at Microsoft that I have heard at NavTechDays is 30.000. Yes, Thirty-Thousand.
You can imagine that these are not everyone daily sold. Not even yearly.
So for the last couple of years Microsoft has tried to clean this up in several ways, but the last one is quite effective I think.
The Certified for Microsoft Dynamics "logo" was introduced some years ago to allow customers to differentiate between all these add-ons and pick the most successfull ones. If you were CfMD a partner had privileges on the Microsoft website and so forth. The hope was also that partners would start selling other CfMD solutions rather than reinventing the wheel, but still you are allowed to sell any add-on with the same commecial conditions as a CfMD product, so that kept on happening.
The big difference between NAV partners and Microsoft is that they have different pillars that drive their business. Microsoft drives sollely on license revenue, new and maintenance, while partners have a big income from implementations.
A NAV partner can sell a license worth perhaps 25.000 euro's but 250.000 euro's worth of implementation and development. Microsoft only gets a percentage of the 25k. So the difference here is 5% vs. 100%. The idea is not to spend the 250.000 euro's anymore but sell vertical solutions worth 75.000 euro's. Here everyone is happy and the partners can do more. This is emphasized by the limmited development capacity that has been hunting the Navision channel as long as it has been existing. The simple rule of thumb is that if we had 50% more developers we have 50% more projects. This will dramatically improve if we do repeatable business.
This does not mean that there are no partners that have made this work. There are partners that sell there solution 20 times per year globaly. But not as many as we should have.
So what's the catch here. I guess my PRS friend and colleague Gary Winter has explained it very well during our presentation at NAV TechDays.
If you want to sell your add-on with NAV2013, you need to sign a new contract with Microsoft. This contract requires CfMD. If you are not CfMD you can still sell your Add-on but you will simply get one invoice each quarter as if you sold the solution. Weather you have a customer or not. And for the Retail object price (with partner discount).
CfMD requires you to have a number (let's asume 10 or so) customers on the current and previous version. So if you never sell your add-on, or only once or twice per year, you are in deep s**t.
But wait. This is not it. This story would not be complete without the Azure story. Microsoft, Kirill Tatarinov anounced this himself on Convergence 2012 that Dynamics NAV will run on Azure in complete multy tenacy mode. This means multiple customers on one database.
As you have read in my previous pust, this has not happened. In my next blog post I will explain a little about Azure and Multi Tenacy technology and explain why this also have a next major impact on the need ot repeatability in Dynamics NAV.
Cheers, and thank you for reading...
UPDATED!... after this post, please also read this and this.
About a year ago Microsoft made a big statement that all next major releases of it's ERP package would run in the cloud on Azure. And the NAV team did some major investments in this and got it to work like it should. Webroles, Workerroles, etc. you name it.
To me it was then a big supprise to go to the "NAV on Azure" session at NavTechDays in Antwerp and hear that it was cut from RTM. Running NAV 2013 on Azure means renting a VM on Azure which is not even released yet.
Personally I think this is a bit dissapointing but I hope and trust that this will be "back" in 8.