ERP Software Logo

Microsoft Dynamics vendors provide comparisons and opinions to professionals in the ERP/Accounting software selection process

 
 

Peter Joeckel, TurnOnDynamics

Paying the Piper or More Real Differences between Microsoft Dynamics NAV and AX


    Email | Print

    The conversation on real differences between Microsoft Dynamics NAV and AX continues as contributing technical blogger and ex-Microsoft product expert Thom Doss continues to sharpen the "real" differences between Dynamics NAV and AX.

    This is part four of a series. To review previous articles:

    Thom continues:

    Let me start with a disclaimer that I should have made abundantly clear at the outset. These articles represent my opinions. They are based on (way too) many years of development experience and engaging with over 100 ERP customers (hands-on project time, support calls, speaking engagements, round table discussions, sales, etc.). They are not based on any confidential or proprietary information I had access to while at MSFT or any of its fantastic partners. Any speculation on potential future direction is exactly that, my speculation based on what I see, read, or hear.

    Earlier, we discussed the issues facing customers who customize their ERP solution, and we noted that these were not just NAV problems. This week we are going to examine why some of them are exacerbated by the nature of development in NAV. Much of what follows is grossly over-simplified because of the wide spectrum of people reading articles like this one. Up until now, I have tried to keep things fairly generic because I wanted to focus on the impact of the technology, and the fact that we can benefit by solving problems in different ways, not drill down into detailed discussions of the values of one technology over another. But since some of the most significant differences between NAV & AX are technical, and the objective here is to evaluate the differences between the products, I’ll need to get a little more technical in the next couple of articles.

    I frequently call NAV the ‘Perfect Pareto Partner’ because it has been the “80-20 rule on steroids” for solution development. In my opinion, (remember the disclaimer?) NAV has long been the industry leader in reducing the time between “thought and executable code.” I continue to be amazed at how much functionality I can deliver with minimal effort with NAV. NAV achieves this “coding bang for the buck” leadership by doing much of the “heavy lifting” in development and letting the IT professional quickly make the modification available to the user.

    However, there are always trade-offs in any attempt to reduce a complex process, and one of the downsides of this simplified development environment is that it limits what can be easily done inside the NAV development environment. One way to say it is that it makes the easy stuff (the 80%) really easy. But it makes the hard stuff (the 20%) much harder than it would have been in a traditional development tool.

    When NAV was created, this was an acceptable compromise for many companies because the development and technology landscape was far less complex than it is today. As Windows and the .Net framework have matured, web integration has become commonplace and traditional development tools have evolved to allow IT professionals to take advantage of new technology. However, NAV development is not significantly different than it was in 2000 before .Net 1.0 (I know I’m going to get blasted for that, but I’m painting with a very broad brush).

    Microsoft’s recent investments in NAV, while considerable, do not appear likely to mitigate these problems anytime soon. Their changes appear aimed at increasing the reach of the existing business logic as opposed to significant changes in how the development of that business logic is done. There have been some wonderful architectural changes that offer manifold improvements in implementation and support for NAV customers. But one side-effect of those changes is that it has actually become more difficult to create most solutions in NAV.

    While NAV is still the leader in “thought to solution” time for many small business problems, the tradeoffs are now more severe. It is much more likely that a customer will need to take advantage of technology that is not inherently supported in NAV. This is when we begin to understand the cost of that sweet music that has been playing as we “whipped out” changes left and right with our magic wand.  Now it’s time to “pay the piper.”

    Let’s look at some reasons the simplified development environment can work against the NAV customer:

    1. The speed of some development in NAV can create an environment that skews expectations and can encourage risk-taking.
      1. This isn’t a treatise on development and I don’t want to get wrapped up in metrics, but hopefully we can agree that the time spent writing code is usually between 20% and 30% of the total solution development process. The rest of the time is spent on analysis, design, testing, documentation, etc. In “normal” ERP development tasks, NAV will typically reduce the coding time significantly, but it doesn’t have the same effect on other areas. When trying to “scale up” with NAV to larger and more complex projects, this can create a “log-jam” in the entire development cycle “downstream” from coding. Things like testing and documentation can get tricky because timing the flow of work in and out of the coding group is much harder. The ratio of development time to testing and documentation time with NAV can be so off kilter as to render many industry standards irrelevant when trying to manage NAV development projects.
      2. It can reduce critical "think" time and emphasize the "code first" mentality. Even the most experienced programmers can fall prey to this; I have not been exempt from it myself. It’s easy to think "ah, that's a quick change, I can knock that out for you," when instead we should step back and be more comprehensive in our approach.
      3. The lack of source code management in NAV is another obstacle to using it in a traditional development environment. It’s not just the lack of version control and a repository; anyone who has ever tried to work with multiple developers and multiple projects in the same NAV DB understands the barriers there. NAV encapsulates so much functionality in so few objects that it is very difficult to isolate independent changes. This makes moving only a portion of the code in testing to production problematic; further contributing to the testing bottleneck.
      4. The gap between what a NAV programmer and a “C#” developer (or anyone who uses Visual Studio and .NET on a daily basis) need to know is significant.
        1. While there are ways to gain access to the .Net framework directly from NAV, it is not seamless and does not support the instant gratification environment NAV users have become used to.
        2. .Net is continuously evolving, and it will be difficult for programmers who do not “live” in Visual Studio to maintain familiarity with the framework.

    Customers who will benefit the most from the recent changes in NAV will be those who need to integrate to other technologies. Ironically, it is when we try to take advantage of this new facility for integration that we realize just how far we have left to go. Let’s look at some examples:

    1. SSRS. The report viewer is a nice rendering engine and I like the tight integration with the RTC, but there are some very real issues with the current state of reporting in NAV:
      1. You leave a lot of capability on the table when choosing the report viewer over full SSRS capability, but attempting to move to full SSRS will quickly expose many of the issues that have kept most NAV customers from embracing SSRS before.
      2. Are you kidding me with the report design process? Let’s be nice and say that this is a “work in progress.”
      3. The ability to resolve some report-related performance issues is hampered by the lack of finite control. Again, choices that are made to isolate the customer and developer from the complexities involved in the “real IT” processes of implementing SSRS properly impose restrictions that can make the remedy to those performance problems very painful.
      4. Web Services:
        1. The NAV web services that come with 2009 solve many of the difficulties integrating NAV with other applications; however, we are mostly limited to simplistic parameters.
        2. The inability to seamlessly consume .Net assemblies or have vendor-provided classes for use in Visual studio still hinder interoperability.
        3. NAV web services are relatively slow, and subject to “initial response” delays due to the real-time compile nature of the new business logic service tiers.

    I’m going to stop there, because it would be too easy to lose sight of the fact that the NAV team has made incredible progress in moving NAV to a new architecture. Many of these issues can be mitigated through customizations and/or ISV products. Pivotier, for example, will make most of the real SSRS-related issues simply vanish. I personally believe that every NAV customer on SQL Server should consider this product. It is simply amazing how much this product does and what it can allow customers to do for themselves. The guys behind Pivotier have a wealth of NAV knowledge and some impressive T-SQL skills. If most of us were considering trying to get the same results from SSRS and NAV on our own, we should remember that “These are trained professionals; DO NOT try this at home.” J

    This is the crux of the issue with NAV as a development platform as it exists today: What it gives in rapid development it can take away when the requirements take you too far from what it does well. The hard stuff becomes so much harder that you can quickly erode the benefits you gained in rapid development of the easy stuff. It doesn’t matter that I can resolve these things; what’s important is that I am aware of them and that I factor the potential impact of encountering these “gotchas” into my decision making process. Many NAV customers will never know about these issues, and those companies will be very well served by NAV for many years to come. But the likelihood of your company encountering some of them and the effort to overcome issues like these are key factors in deciding which ERP to use.

    It’s important to remember that most of these limitations have been here all along and NAV is one of the most successful products on the market. Why am I saying all of these “bad” things now? Has NAV has gone backwards? No, NAV has not gone backwards, but a case could be made that the definition of the “right fit” for NAV is different now than it was before. I am only pointing out these issues because to truly understand the real difference between the products, you need to know the situations where the differences move from cosmetic and surmountable to fundamental and overwhelming.

    Does that mean NAV isn’t good for development? Not just no, but “Hell No!” NAV is a fantastic product that will flat out spank most competitors in the “Time to Value” equation when it is the right fit. What it does mean is that you must do a thorough job of evaluating your requirements and understand how you wish to leverage technology in your business to understand the impact of some of the fundamental differences between AX and NAV. And it means that you must be very careful as you approach the gap-fit portion of your decision making process because a lot of things have changed.

    If you think you know where this is going, I ask you to stay tuned. If I haven’t made it clear before, I am a huge fan of both products, and I think some of my conclusions and recommendations may surprise you. Next week, we’ll take a look at AX 2012 and how the game has changed. Then as promised, we’ll bring it all together in the conclusion of the technical comparison.

    Peter Joeckel is the President and Founder of TurnOnDynamics a Microsoft Dynamics Partner servicing Texas, Oklahoma, Louisiana and Arkansas (TOLA) manufacturing firms. TurnOnDynamics has extensive experience with Microsoft Dynamics GP, NAV and AX.

    TurnOnDynamics focuses on the strategic concerns of executives and owners with a unique Dynamic CFO Service.

    Thom Doss has a long and distinguished career in the ERP software field. He has worked in the partner (VAR) community, at Microsoft, and has been on the customer side of the fence. He is a certified developer on a number of platforms, including Dynamics NAV and Dynamics AX. He is also a MCSD, a MCDBA and works with clients and partners to leverage SharePoint and Dynamics CRM in the context of their ERP implementations.

    Thom is available on interesting projects that concern manufacturing, sophisticated but troubled Microsoft Dynamics NAV implementations, and Dynamics NAV to AX projects. He can be contacted directly by leaving a note here or on his LinkedIn page.

     by TurnOnDynamics

    Ask This Expert a Question / Leave a Comment

     

     
     
    Live chat by BoldChat
    Show Buttons
    Hide Buttons