So how do you see the Dynamics future comparing to Oracle and SAP?

A friend on Facebook asked this question yesterday.

My initial answer was that I don't think that we'll see any big changes in the market with the products we have now. I think that both Dynamics NAV 2009 and Dynamics AX 2009 a really great products. Great usability and functionality.

Microsoft's semi-enterprise product Microsoft Dynamics AX is a great product. But compared to the SAP and Oracle Financials to really make a difference. In many ways it's "just another product".

Microsoft Dynamics NAV 2009 is also a really unique product. It's user interface is giving the users a great experience and is allowing it's users to customize their own views to make it even easier for them to use. But what hurts Dynamics NAV 2009 is that performance is not what you could expect from such a great product. If you have much more than a few hundred users, then you cannot use the program without having to do extensive performance optimizations of the code. And if you want to support more users, then it is a huge task that only very experienced SQL specialists can do.

I believe in Dynamics NAV, because of its unique usability, easy implementations and it's very simple development platform. What needs to go away is its support for its own database, the native Navision database. As good as this database has been in the past, especially when it comes to supporting smaller installations, as bad it is when it comes to add scalability and performance.

So I really cross my fingers for what Microsoft is planning for Dynamics NAV 2011 (the next big version after NAV 2009).  I think if Microsoft finally will kick out the native NAV database and only support Microsoft SQL Server, then the solution can really be optimized, so that NAV will be able to both cover the SMB and the Enterprise markets. But Microsoft needs to take it serious. It's not enough that they skip the native database. They also need to optimize the code. Not just leave it to their partners.

But if they do, then I think that they really will have a product that will both be able to compete the normal SMB markets and the Enterprise markets, and especially in the Enterprise market will make a difference, with it's almost extreme ease of use.

Comment List
  • 2 remarks:

    1) "...that only very experienced SQL specialists can do." is not completely correct. A pure SQL specialist cannot do a lot (Except creating a lot of problems if he tunes the indexes directly in SQL). You need a NAV-on-SQL specialist to do SQL-tuning for a NAV DB.

    2) Do you think that SAP or Oracle don't need tuning? Someone once told me that for a SAP-installation, they sell immediately not just a few days of tuning, but about 20 days of tuning.

    With NAV, for a long time tuning was not needed with the native DB because it is a very fast DB-system. Performance tuning for NAV was something "alien".

    And now with SQL (together with bigger implementations and more functionality), performance tuning has become a necessity. But the NAV-commercial people are still not used to the fact that they should sell some performance-tuning days for SQL.

    In my company I have told the commercial people to include in the contract also 3 days of optional SQL-tuning (as time-and-material. If no tuning is necessary, they don't pay this part). Without these 3 days, it is a lot more difficult to explain that they have to pay for some tuning. Now we can just refer to the contract that we have foreseen the possibility that tuning will be necessary.

  • They need to stop support sooner starting with SP1 and introduce performance and scalability features in SP1. But my guess is that they probably focusing on RTC bug fixes and usability.

  • I think it will not be possible for them to stop supporting it with the introduction of a service pack.

    This is a major change, a required major change, and if it should be good, then they shouldn't just stop supporting the native database, they should also update the objects accordingly. Otherwise it's just half worth it.

  • Well they have guaranteed support (as in current versions) for Native up till 2012. So either its 2003 for SQL only, OR they are going to have to start supporting two versions.

  • But did they guarantee support for the native in all new versions until 2012, or did they just promise that they'll support the current version (incl. native) until 2012?

    And is it only 2012, don't they normally say 5 years after the release?

  • "... They also need to optimize the code ..." - well, I think the main problem concerning performance is not the code but the data structure. Consider for example the posting principle in G/L with its continous Entry No. in the Ledger Entry tables. This principle is in obvious contradiction to a multi user environment where many users want to post G/L Entries simultaneously instead of sequentially... - the solution lies in choosing another primary key. Instead of Entry No. one could use Document No. in the Ledger Entry Tables, e. g., and the users can post within their own No. Series simultaneously using record (or page) locking on the SQL Server.

  • ghuebner:

    Situation with EntryNo is a classic sample of what happens if program is initially designed singleuser and then you make v2.0 and proudly announce you've gone multiuser...

    Navision principles of linking entries in different ledgers by means of this EntryNo simply don't allow this to be changed without TOTAL redesign of all data structures, and, consequently, rewriting the code  - and how MS can do it with such a huge installation base?

    There is no need of inventing a bicycle - every normal DBMS has field of type Identity Column, just for PKey purpose, question is, how to replace/redesign the entry linking system in NAV. Some time ago Val Gvozdev announced here a solution he called Locking Free NAV - I have a hard feeling he has gone this way (he did't publish the principles, altogether it's a commercial product). However, I don't know if such changes doesn't go beyond C/AL and into .exe already.

    ~10 years ago I led a team designing an accounting system (nobody could afford NAV or alike then in my country), it took us one additional year for release, but it was built from scrach taking into consideration it will be multiuser.

    So, having been a programmer and analyst in past, I simply can't see how MS will be able to do such huge changes:

    1. bye bye native DB

    2. then they can rewrite code to use SQL functionality at its fullest

    3. redesign data structures to get rid of consecutive counters (including EntryNo as PK), where possible - these really are performance killers if you have several thousand users

    4. ...going Unicode then will be automatic :) - such a big problem silently disappears  

    and keep the product still NAVISION as we know (and love?) it.

    After writing all this I suddenly remembered what MS promised when bought all four ERP systems - after some time there will be no NAV, AX, GP and SL - there will be one common product with all the best features of each of them joined...

  • I believe that support for Native will go soon, maybe even with the next version, because Service Tier doesn't work with it anyway. I don't think it would be a smart decision to make Service Tier compatible with native database, so my strong opinion is that it's going to be phased out.

    I don't remember that there was 2012 commitment, but there surely was 2013 commitment for development of specific Dynamics applications (NAV, AX, SL, GP), but that commitment was dropped about two years ago, when it was announced it was no longer a core goal.

    Current position is that there are 4 different ERP systems, and that all 4 are going to be developed and maintained. Whether complete convergence into a single Dynamics ERP will happen over time, remains to be seen.

    In this light, I don't believe Microsoft will invest much into growing NAV's scalability much further. When native is phased out, SQL can be leveraged through code optimization, but I don't think there will be any revolutionaty changes to NAV. With 5.0 it nominally supported 250 users. With 2009 no figures have been given out, but I believe it is about the same figure. You can go above, sure, but with some preparation and architecture considerations. With 2009 and beyond I don't believe there would be a goal to go farther beyond 400-500 users.

    Also, Microsoft positions AX strongly as an enterprise product, and NAV (and others) as mid-market products. I believe they will continue to invest more into AX, and will expand it into markets where it didn't exist already. I believe that for Microsoft it makes much more sense to differentiate between these two products, than to have them comparatively scalable, because it creates competition with own products--it's not in Microsoft's interest to have NAV compete with AX, when they can easily say that NAV is for this or that size, and AX for everything larger.

    But NAV is going to be an increasingly better application. With native database gone, you open the door for many enhancements other than scalability: as Modris Ivans said, there is unicode, which will be a huge improvement much more meaningful to mid-market than increase in scalability.

    Now, this is my personal opinion, not necessarily that of my employer :-)

  • Vjekoslav - you regarding the 2013 for NAV, AX, SL, and GP that this commitment "was dropped about two years ago, when it was announced it was no longer a core goal."

    I think it is worth clarifying that when Microsoft first put out that 2013 date it was several years ago, when 2013 represented maybe a ten year window. It was sufficient at the time because that was beyond the assumed lifetime of an ERP implementation.

    They pulled that commitment because as the date approached it created more concern than comfort. Did it really mean that the current Dynamics products only had four years of life remaining? No. At this point Microsoft will develop, enhance, and support them beyond 2013. The date just didn't make sense anymore.

    I'm thinking this may be what you meant with your comment, but wanted to clarify just in case.

Related
Recommended