mibuso.conference: Dynamics NAV 2009 and Beyond

Administrator

mibuso.conference: Dynamics NAV 2009 and Beyond
Session presented at the first mibuso.conference.

Agenda

- Status on Dynamics NAV 2009
- Dynamics NAV 2009 SP1
- Dynamics NAV 2009 Roadmap
- Technical deep dive:
- Dynamics NAV Architecture in the past, presence and future
- Future Toolset and Language
- C/AL testability framework

http://www.mibuso.com/dlinfo.asp?FileID=1104

Discuss this download here.

ara3n

This is very interesting slides, and I'm happy that MS NAV is releasing the info.
It's interesting that they are still looking at the next C/AL language and considering C# pro's and con's.

This would be a very good discussion

The big Q: What do YOU think as NAV partners?

I'm all the way for C#. The syntax changes can be learned and are so minor compared to all the advantages.

kriki

cons:
In C it is possible to make errors that are very hard to find (I don't know how much C# looks as the old C). A lot of those problems are impossible in C/AL. But a better (=Real) editor like Visual Studio and a good debugger would be very welcome.

The problem is not really to find programmers for NAV. The language is easy enough to learn. The problem is to find programmers that understand the NAV-way of programming things. If C# is used, a lot of C# programmers will start programming NAV (Hey, it is C# and I am a C#-super specialist!), creating a lot of problems. (a little bit like a SQL-guru that starts tuning a NAV-SQL DB without knowing NAV!).


In short I am more for keeping the C/AL, but moving it in Visual Studio to have those editor+debugger-capabilities (of which, actually, I know very little) .

kine

I hope that the development will never ends in "Visual Studio". Own editor with all the features will be good, but without the things around which you will not need in NAV. Debugger, yes, if the debugger will be the VS one, no problem. But developing in VS for NAV will means what Kriki described (about the developers). Enough that you will be able to extend the client with own addins. This will lead to heavy customized clients, where all editboxes are done through addin etc.

ara3n

kriki wrote:

cons:
In C it is possible to make errors that are very hard to find (I don't know how much C# looks as the old C). A lot of those problems are impossible in C/AL. But a better (=Real) editor like Visual Studio and a good debugger would be very welcome.

If you mean by using pointers, in safe C# you cannot use pointers. CAL programmers will be using only a subset of the libraries. After all we just writing business logic. The ability to use everything else that C# offers would be great.

The problem is not really to find programmers for NAV. The language is easy enough to learn. The problem is to find programmers that understand the NAV-way of programming things. If C# is used, a lot of C# programmers will start programming NAV (Hey, it is C# and I am a C#-super specialist!), creating a lot of problems. (a little bit like a SQL-guru that starts tuning a NAV-SQL DB without knowing NAV!).

Every ERP system has an issue when a new person starts development. Using a different language won't prevent from those problems.
The programming environment is still controlled through the RTC so they will be limited on what they can do.
Based on your example about NAV-SQL DB, then NAV should have never moved to SQL because you would have SQL-guru start tuning with the DB or
user would modify data directly on SQL.

In short I am more for keeping the C/AL, but moving it in Visual Studio to have those editor+debugger-capabilities (of which, actually, I know very little) .

This requires a lot of investment that could be used in other areas. Having a scalable NAV is more important than using one syntax over another.
It doesn't make sense to invest in C/AL.

Having C# as business language will be also a great selling point to get IT of a client on board.

I get constantly bitten by limitation in C/AL.

ara3n

kine wrote:

I hope that the development will never ends in "Visual Studio". Own editor with all the features will be good, but without the things around which you will not need in NAV. Debugger, yes, if the debugger will be the VS one, no problem. But developing in VS for NAV will means what Kriki described (about the developers). Enough that you will be able to extend the client with own addins. This will lead to heavy customized clients, where all editboxes are done through addin etc.

Based on their slides, you start the modification in RTC and only go to the editor write code. Whether the editor is in full blown VS or subset, it wouldn't matter.

The important part is that it needs to be started from RTC. Just like in 2009 you start the report designer in NAV and then go to RDL editor.

I am also happy that they are creating a new Query object type. I'm assuming we will be able to use it in programming as variables.

David_Singleton

kriki wrote:

The problem is not really to find programmers for NAV. The language is easy enough to learn. The problem is to find programmers that understand the NAV-way of programming things. If C# is used, a lot of C# programmers will start programming NAV (Hey, it is C# and I am a C#-super specialist!), creating a lot of problems. (a little bit like a SQL-guru that starts tuning a NAV-SQL DB without knowing NAV!).

=D>

ara3n

Just because I know C# doesn't mean I can go and start modifying MS CRM. Same will apply to NAV


Look at LS retail for example. Some of the people developing it probably didn't know Navision and if you look at the code it's evident, but it didn't stop them from modifying Nav.


You cannot prevent problem from occurring with just using a different Language. Just look at some of the questions I see mainly from India in here.

I see usage of C# as plus, mainly because the user will need to think before slapping code.

I see many consultants that don't know programming but can slap NAV code and it works to certain extend and they move on. And then I'm stuck with rewriting and cleaning up the code.


If NAV will control the transaction and rollback mechanism. Then it all comes down to syntax

SimonW

Pity we aren't able to see the powerpoint as MS asked for it to be pulled (for those of us who didn't attend).

Administrator

mibuso.conference: Dynamics NAV 2009 and Beyond
Session presented at the first mibuso.conference.

Agenda

- Status on Dynamics NAV 2009
- Dynamics NAV 2009 SP1
- Dynamics NAV 2009 Roadmap
- Technical deep dive:
- Dynamics NAV Architecture in the past, presence and future
- Future Toolset and Language
- C/AL testability framework

14/07/2009: Revised version available for download

29/06/2009: Download removed per request from Microsoft marketing department

http://www.mibuso.com/dlinfo.asp?FileID=1104

Discuss this download here.

j.marselo

My opinion is practically not for it. However, if we want to preserve our business, we have to go along Microsoft's way. I think Microsoft is pushing way to much to break and smash 'Navision' to eat, wear, and sit upon other Microsoft products.

There is a different face of Navision when the time Navision was born to the world and world got acquaintanced with the software. The appeal of Navision is easiness, easy to deploy, easy to use, easy to modify, easy to fit, easy to integrate, and you can continue the list. The face of Navision is now far than that, not only change of name into Dynamics en.ei.vi, but it also gets more difficult to install because (on NAV 6 - 2009) people has to deal with SQL Server 2005 and up, SQL reporting service, server this, server that, and so on.

It's not simplifying any businesses, instead, it will increase the cost of ownership of the solutions (software, middle wares, project implementation, maintenance and support). Anyway, Microsoft is always put in the front the idea of TCO and ROI, where I can only see a fiction description and interpretation in one of Microsoft white papers.

I will think if I ran a business, when I have a software that runs well, and I will keep it. If I am a business owner, then I met 2 consultants to discuss about what solutions fit my operation, consultant A suggest, " ... use software A because it has own database, your existing IT people need to involve in implementation, and that's it" ; and consultant B suggest, "... this software B is amazing, when you have server A running as database server, then one more server running as business logic, then your organization is equipped with a professional specializing on X and a professional specializing on Y, ... then it's the time you can get the benefit of using this software B". You know what the decision will be, for sure.

A factory, a plant, a store chain, a distributors, retailer/reseller, any businesses, they do not care about the software. They care on how the MPS runs, how MRP runs, how to manage orders, how to control inventory, how to track the job, and so on. They care on the functionalities and capabilities of the solution. When one good software serve their needs well or very well, they are reluctant to change. Or if they want to change, they will ask upfront, what that upgrades do good for us?

Upto version 5, NAV is still make sense and nice to my taste. Version 6 is starting to become doesn't make sense, and this presentation, I'm afraid it will go insane and non-sense.

This is my personal view ...

generic

Hello Joe Marselo
I agree with several point of your view, but I suggest to be careful when you post negative facts in here about NAV.
There are people in this forum who will belittle you and discredit you. It almost looks like fanatic fanfare or religion.

kine

generic wrote:

Hello Joe Marselo
I agree with several point of your view, but I suggest to be careful when you post negative facts in here about NAV.
There are people in this forum who will belittle you and discredit you. It almost looks like fanatic fanfare or religion.

It have nothing with negative facts or something, it is just about discussion and facts and used words etc. Yes, sometimes someone goes personal, but in most cases it is because text and language limitations...

I do not like some things too, but from another side, I understand the background for some unpopular steps...

---

The NAV 2009 was mainly about the technology change. Next version will be more about functionality (you cannot focus on both in one version). We will see what MSFT will prepare for us... 8)

generic

kine wrote:

The NAV 2009 was mainly about the technology change. Next version will be more about functionality (you cannot focus on both in one version). We will see what MSFT will prepare for us... 8)

Actually the version after next version NAV 8?. From what I understand the next version will have SharePoint front end.

kine

Yes, but it was planned for NAV 6, but postponed. What MSFT told is that now they need to focuse on functionality, because it is long time when something from this side was changed (excluding the "small" changes...). We will see what the future will bring...

Alex_Chow

Hey Joe, I agree with you 100%. I also believe the ease of deployment and customization is significantly hindered by the new GUI.

The new GUI doesn't introduce anything amazing other than that it's a new GUI. What they should've done is to kept the classic client as is, then introduce the new GUI as only a sharepoint and/or web interface.

Unfortunately, Microsoft is imposing their will on all the dynamics products in order to sell more total software. Microsoft is a software sales company, not a service company. So if they make their software interdependent, they will sell more software.

It's good and bad. Some company really dig the fact that all the MSFT products can be used together. Others believe they're trapped by Microsoft. In either case, you can find people on both sides of the spectrum.

The pressure to lower the total cost ownership of Microsoft products is happening with the introduction of some key software such as Exchange, sharepoint, CRM, etc online.

generic

Alex Chow wrote:

The pressure to lower the total cost ownership of Microsoft products is happening with the introduction of some key software such as Exchange, sharepoint, CRM, etc online.

But it's going in the opposite direction for NAV.

Active Directory
SQL Server
Server tier
MS Office.
Upgrades are Most expensive, and sometimes Impossible. Most customers have about 100 reports.
If you upgrade each 8-16 hours per report. That's 800-1600 hours. Try to give that quote to your customer.


Next they'll integrate SharePoint. Not a requirement but it's how they'll eliminate 3rd party solutions.

Alex_Chow

generic wrote:

If you upgrade each 8-16 hours per report. That's 800-1600 hours. Try to give that quote to your customer.

Perhaps I haven't done as much upgrades as you, but I've never encountered a report where it takes 8-16 hours to upgrade.

generic

Alex Chow wrote:

generic wrote:

If you upgrade each 8-16 hours per report. That's 800-1600 hours. Try to give that quote to your customer.

Perhaps I haven't done as much upgrades as you, but I've never encountered a report where it takes 8-16 hours to upgrade.

That's MS suggestion estimate on how long it takes to upgrade a 4.x or 5.x report to 2009 with layout.
Naturally if you you do a lot of them, it gets faster.