ERP Software Logo

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


Peter Joeckel, TurnOnDynamics

Sustainable Engineering in Microsoft Dynamics NAV and AX or More Real Differences between Microsoft Dynamics NAV and AX

    Email | Print

    In our recent post More Real Differences between Microsoft Dynamics NAV and AX we started a conversation with Thom Doss regarding the dramatic differences between Microsoft Dynamics NAV and AX.

    In that introduction for this series, Thom promised you Workflow Foundation (WF) and SQL Server Reporting Services (SSRS) this week, but feedback from readers convinced me that we need to provide some examples of what is meant by “sustainable customization” in both NAV and AX. Here is the schedule for the remainder of the technical part of the series:

    1. Intro - Industry trends in customizable ERP
    2. Intro - Sustainable engineering in Dynamics AX and NAV
    3. Intro - Leveraging SSRS and Web Services
    4. NAV Development - Paying the piper
    5. AX Development - Bringing a gun to a gunfight
    6. Conclusion – Technical

    Last week we introduced the comparison by looking at the issues faced by companies when extending any ERP solution, not just NAV or AX. I now think it will take at least two more articles to cover just a few of the horizontal or enabling technologies that are (or should be) in use in most companies evaluating NAV or AX. The capability to ‘fully engage’ with technology like this should be considered the minimum expectation when evaluating customizable ERP products.  For these articles, this extended introduction will represent what I was referring to when I wrote “All things considered” last week.

    Earlier, we examined several design objectives that companies should use when customizing ERP solutions. In this article, I want to provide examples for two of those:

    1. They need to customize in a way that allows them to upgrade more easily and more often to take full advantage of investments the publisher is making in the product.
    2. They need to leverage external tools that can extend the business logic and collaboration to people who may not have the ERP client, or may not have access to the client all of the time.

    The companies that gain the maximum benefit from an upgrade to (or new implementation of) the current NAV and AX versions will be the ones with the vision to see the value of integrating with other programmable solutions:

    1. They will be in a position to benefit from the architectural changes Microsoft has made to the products.
    2. They will be able to evaluate their approach to customization in light of technology now available and lessons learned from the past.
    3. NAV and AX customers upgrading to the current versions should challenge existing customizations and re-do many of them in light of these design patterns.

    The most obvious new enabling technology for them to consider is the Role Tailored Client. Here are just a few examples of ways you can design/redesign customizations to realize process improvements and improve the sustainability of the solution.

    1. Design pages to take advantage of users’ ability to make UI changes like:
      1. Changing the order of fields on pages.
      2. Make fields optional, invisible, or remove them completely.
      3. Move the location and change the visible contents of fact boxes.
      4. Choose between multiple fact boxes tailored to specific:

    i.      Locations

    ii.      Job types

    iii.      Local legislation

    iv.      And many more

    1. Increase the sustainability of your solution by looking for ways to accomplish visibility and notification ‘customizations’ by enabling features that users can use to make these choices for themselves. The RTC gives us incredible capability, but it will require some changes in the way we approach development to maximize the benefit of that capability.
    2. Take advantage of the Action pane to encapsulate business logic so that it can easily be reused on many pages. With minor changes, it is often possible to aggregate several independent but similar modifications into a single procedure or function with options. This not only reduces the impact of a global logic change, but it also reduces the number of changes you have to evaluate during an upgrade.  The architectural changes in the product(s) make it easier to implement this type of ‘sustainable engineering’ change.
    3. Move schema changes to related custom tables as opposed to making them in base objects. New technology available in the RTC makes presenting data from multiple data sources much easier than it was in the past. If you minimize changes to base objects, you reduce the amount of work you have to inspect during subsequent upgrades. Even the most trivial of schema changes can have unanticipated consequences during an upgrade. Isolating your changes to custom objects will save you money every time you upgrade.

    Another opportunity to improve long-term TCO is to take advantage of the fact that it is easier to integrate horizontal technologies with both products than it was in previous versions. In a truly holistic IT solution, the ERP is only a piece of the solution. Here is a simple example of how to leverage workflow foundation in .Net 4.0 and SharePoint 2010 with NAV 2009 R2. (The same thing can be done in AX 2012 with even less effort).

    1. Create a notification codeunit (CU) in NAV that will create a document in a SharePoint library with the table and primary key (at least) of rows that may have a workflow associated. Call this code from the global DB functions in CU 1 (I didn’t say we would never modify source code) when a record changes in NAV.
    2. Create a library-based workflow that reviews the table that was changed and decides which other workflow(s) to execute. This workflow can reach back into NAV through web services to retrieve any additional information required to process.
    3. With a little creativity and effort, it is possible to base many decisions in workflows on row based data (or even meta-data), giving you even greater sustainability. Examples are:
      1. Libraries that define which users are to be notified when a specific table or even a specific field in that table changes.
      2. Libraries that define which users are to be involved in specific steps in a workflow, and the condition(s) on which their participation depends.

    At first glance, this may seem like more effort than just coding the notification in NAV or AX. But here are just a few benefits that offset the increased ‘acquisition cost’ of the modification:

    1. The changes in the base ERP can be isolated to a small change in the global database section. This change can initiate workflows for many tables.
    2. Everyone in the enterprise can participate in the workflow, not just ERP users.
    3. The participants in the workflow are not required to have access to the rich client to ‘move the process along’.
    4. The workflows themselves are row based, not source code based. This means that:
      1. You can have multiple people creating workflows simultaneously for the same table.
      2. Two different workflows can execute in parallel based on the same change, and an error in one will not affect the other.

    There are many more benefits to be found in this kind of integration, but just think about these two for a few moments. It is difficult for two people to work at the source code level in NAV on the same object. It is also difficult to write AL code that handles all exceptions and will guarantee that “downstream code” executes in all conditions. I’m not saying that you can’t do those things in AL or that you would want to do them in every occasion. I’m simply pointing out that we can accomplish both of these things in a sustainable, almost ‘upgrade neutral’ fashion through workflow foundation.

    These articles are not intended to be comprehensive guides to development, merely examples of how we can increase the reach and sustainability of our customizations.  For a far more in-depth look at “sustainable engineering” with ERP, download Chandramouli Venkatesh’s white paper.

    To properly compare NAV & AX we need to understand how each fits into a holistic IT solution. Next week we will conclude our look at horizontal/enabling technologies and then we will be ready to start comparing the products from an extensibility standpoint.

    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


    One Response to “Sustainable Engineering in Microsoft Dynamics NAV and AX or More Real Differences between Microsoft Dynamics NAV and AX”

    1. Dear Sir or Madam

      I am looking for a comparison between functionalities og Dynamic NAV 2015 and Dynamic AX with focus on manufacturing. We have mixing processes of plastic to the Medical industry with high demands for lot-trace, documents etc. Does this comparison exist?
      Here I find nothing relevant.

      Morten Simonsen
      M. Sc. Chem. Eng.

    Ask This Expert a Question / Leave a Comment


    Show Buttons
    Hide Buttons