ERP Software Logo

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

 
 

Peter Joeckel, TurnOnDynamics

Bringing a Gun to a Gunfight 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 five of a series. To review previous articles:

    Thom continues:

    Microsoft has made significant investment in AX over the last few years, and it shows when you look at the current versions of the products side by side. Earlier in the series, I invited you to read a white paper outlining development patterns available in AX 2012. A quick glance at the white paper should tell you that Microsoft is focused on delivering an environment that can be extended in many ways, allowing you the customer to choose the method that works best for you in each scenario.

    1. You want to simply extend the reach of the existing logic? Feel free through Enterprise Portal or create your own simple applications and surface all of the great AX logic anywhere you want it through services.
    2. You want to add your own business logic extensions to AX? No problem. Would you prefer to develop in X++ or a C#, or …?
    3. Would you like to add your own existing C# code to the repository of functions available in AX and be able to seamlessly call it from AX? No problem.
    4. Would you like to use built-in workflows for approvals? Write your own? Write custom workflow actions in C# that evaluate data in other systems before continuing?
    5. How about all of the above? No problem. “Have it your way” as the commercial says.

    I could go on, but if there is any doubt in your mind that AX will complement and/or enhance your existing development efforts, please browse the white papers available on MSDN for AX development, and Mike Ehrenberg’s introduction of AX 2012 to get a feel for the scope of the technical capability Microsoft has built into AX 2012. No other product I know of gives you so many ways to extend the application, from rule based options like work flow and policy management to true object oriented source code development, and everything in between. This is one of the key strengths I see for AX when compared to most products. You are free to innovate in the way that works for you. You are not “boxed-in” to a given “development pattern” and many companies will choose to use several options in their solution.

    If you have seen any AX 2012 presentations, you’ve probably noticed a recurring theme of “PAS.” (Powerful, Agile, Simple) Since this is the technical portion of our comparison, I will be focusing on features that mostly fall into the “Agile” bucket. And since we are comparing AX and NAV in this series, here are a few of the areas where AX has distinct development and technology advantages over Dynamics NAV:

    1. Unified Natural Models - Too often organizations are being forced to 'fit' the rigid organization and business process models that exist in the ERP software, the design is often 'hard coded' and cannot be easily modified, requiring code development work to change. AX 2012 provides unified natural models that let you see, measure, and change your business without having to modify the source code.
      1. Model Driven Layered Architecture - MDLA allows partners and customers to build solutions more quickly.
        1. AX tracks source code at different layers (Base model, localization, industry specialization, ISV (vertical) specialization, reseller specialization and customer specific customization) to accommodate independent development. Keeping these changes isolated to a given layer helps prevent many of the object conflicts that plague complex NAV implementations.
        2. This also allows us to model very granular changes and effectively manage the application deployment lifecycle.
        3. It is much easier to have multiple developers on an AX project, and integrating to source code management tools is easier.
        4. In addition to isolating changes to layers, AX splits functionality into smaller, “more discrete” pieces than NAV. You will still have to exercise good development discipline, but moving pieces of functionality from testing to production will be much easier. You will spend much less time merging development branches with AX than you would with NAV.
        5. AX can be the source code repository or can integrate readily into industry standard programs like TFS.
        6. The AX development environment is far more versatile and truly object oriented, not object based. To grossly oversimplify the last the 18 to 20 years of software development advances: code re-use is the holy-grail of development, and object oriented programming allows developers to more easily create reusable code.
          1. AX 2012 extends inheritance to tables. Read Yanning Lui’s white paper when you have some time on your hands to consider the impact this can have on scale and agility. That doesn’t really belong in this document, but when you are ready to dig deeper, prepare to be amazed at another example of how Microsoft is making AX “bigger, stronger and more agile.”
          2. Not only does AX have queries that can be used as a data source for forms and reports, but AX has join types that you will not find in other packages. My personal favorite is the “not exist” join. How nice to be able to seamlessly find all the rows in a table that do not have a corresponding row in another table.
          3. Programmers used to working in Visual Studio will find AX easy to learn as X++ looks much like C# or Java.
          4. AX 2012 has post and pre event handlers available to help isolate custom code.
          5. AX 2012 has workflow foundation capabilities.
          6. It is easier to access AX business logic from Visual Studio than it is to have the same access to NAV logic:

    i.      .Net Helper classes for AX are available in Visual Studio to facilitate directly interacting with AX in a tightly coupled manner while programming in your language of choice.

    ii.      AX offers three different data source types (Query, Report Data Provider, Data Methods) allowing you to build more comprehensive reporting solutions when the business requires it, but retaining simplicity for the “easy stuff.”

    1. Pervasive Interoperability – As we saw in the first three articles, seamless, pre-built interoperability between ERP, Office and other technologies is mandatory in today’s IT landscape. AX offers productivity and familiarity by design through pre-built interoperability with Microsoft Office and SharePoint, extending the reach of the ERP solution within an organization. Allowing you to seamlessly manage structured (ERP) and unstructured (Office documents) data in the same experience enhances the benefits from leveraging these technologies. NAV has very nice capabilities to export data to Office, but AX 2012 includes Office integration code to allow a customer to download data to Excel, edit, and send the data back to AX. The impact of this kind of interoperability with productivity tools like Office cannot be overstated.
    2. AX has had SharePoint integration with enterprise portal (EP) for many years and MSFT is extending this integration with search and other unique business processes. Click hereto see a list of EP features in AX 2012 where you’ll read that EP includes the following sites where users can access data and participate in the business processes:
      1. The Procurement site
      2. The Sales site
      3. The Compliance site
      4. The Project management site
      5. The Service management site
      6. The Employee Services site
      7. The Vendor self-service site
      8. The Customer self-service site
      9. As you would expect with rich .Net integration, AX can compile X++ into CIL. Again, to grossly oversimplify the benefits of .Net:  Managed code is significantly faster and safer than unmanaged code.

    Many of these features enable sustainable engineering for customizations on a scale that is simply not feasible with NAV. And as I wrote earlier, you have far greater control over when and where things are happening with AX 2012 than you do with NAV. If you want the X++ code to be interpreted by the run time, just don’t tell AX to compile all the way down to CIL. If you want to execute complex X++ code during your report, then use a Report Data Provider. AX offers simplicity when the problem is simple, but does not penalize you when you need to do “real” programming. If you are looking for an ERP that fits well into an enterprise class IT infrastructure, you may have to look a long time to find one that fits better than AX 2012.

    Does this mean we should all abandon everything else and only consider AX? As I wrote last time, “Not just no, but…” A lot of these new capabilities are a double-edged sword for Microsoft and AX partners. The changes open up new avenues for them, but they have to change the way they solve problems to fully benefit from them.

    Much like Microsoft essentially “broke up” the architectural changes to NAV into 3 releases (NAV 2009, NAV 2009 SP1 and NAV 2009 R2), I believe that AX 2012 is just a significant first step in delivering the future of “truly integrated” ERP. As much work as Microsoft has done (and there are literally thousands of improvements in AX 2012), they still have a lot of work ahead of them to refactor all of AX to take advantage of these new technologies. Here are a few things that indicate to me that AX 2012 is still a work-in-progress:

    1. They need integration between the organizational model and workflow framework.
    2. The policy framework is a good start, but it needs to be more deeply ingrained everywhere in AX.
    3. How about some better integration between SharePoint and AX workflows?

    So in a sense, Microsoft has more work ahead of them with AX than they did before because they have obliterated some of the barriers that stood in the way when we wanted to reach deep into our “programming bag of tricks” inside the ERP. They have raised the bar on what we can do when extending our ERP, and should we not expect our ERP provider to demonstrate “thought leadership” when building/rebuilding that ERP? I can’t wait to see R2 for AX 2012 to see how they deliver on some of the promises in AX 2012.

    A significant risk to the customer implementing or upgrading to AX 2012 today is finding people who understand how to leverage these new capabilities. Most AX consultants and developers have a lot of work ahead of them to learn to re-think the way they approach solving problems with AX 2012. But just as I must change my approach to truly benefit from the changes in NAV 2009, many of the sustainable engineering benefits available in AX 2012 will only come if we change the way we work. Implementing AX 2012 like I would have implemented AX 2009 would be a travesty and could be just as big a mistake as buying the wrong ERP, maybe worse.

    AX 2012 is a game changer, but we have to understand that we are in a new game for the customer to realize the maximum benefit. Profit requirements always put pressure on partners to maintain billable hours, sometimes at the expense of training. Some will try to have their consultants and/or developers “learn on the fly” while implementing the new version, as they have done in the past, and that could have significant impact on the value received by the customer and the time to receive that value.

    Another risk with AX 2012 is implementation burden. It is an inescapable fact that the more comprehensive we make our software, the more complex we make the installation and configuration of that software. With AX 2012, Microsoft has increased the capability of the product by orders of magnitude, and in many ways, we are all playing catch-up. Microsoft is on the right track to helping partners mitigate this burden with “RapidStart,” and many partners are embracing the changes since they will allow us to deliver more value in less time and ultimately for less expense to the customer than with any previous version of AX.

    It took us a while to get here, but I think the readers can now understand why I wrote in the first article that it was getting harder to find situations where the best fit for a given customer wasn’t fairly clear.  Agility means different things to different companies, and AX and NAV offer different paths to allow companies to “make it mine.” Next time I’ll wrap the technical comparison up with some conclusions and recommendations for companies considering AX and/or NAV. At this point, some of you are realizing the reason I made the CRM reference. That will come into play as well in the next article as I (hopefully) fulfill my promise to surprise you with some of my recommendations.

    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 uniqueDynamic 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 - a Microsoft Dynamics Partner servicing Texas, Oklahoma, Louisiana and Arkansas (TOLA) manufacturing firms.

    One Response to “Bringing a Gun to a Gunfight or More Real Differences between Microsoft Dynamics NAV and AX”

    1. len amin says:

      i was wondering can you differentiate NAV 2013 and AX 2012 R2?

    Ask This Expert a Question / Leave a Comment

     

     
     
    Live chat by BoldChat
    Show Buttons
    Hide Buttons