mibuso.com

Hi guys,

I want to refer to a question that was asked at the NAVTechdays 2011 and about that I also thought in the last few month. It was the first question in Christian Abeln session and I think Christian didn't give a proper answer to this question. I mean from a certain point of view this is the only answer someone from Microsoft could give. But there's also some truth in what you could read between the lines of this question.

In general the question was about: What kind of methodology does Microsoft (or someone else) provide to qualify traditional NAV developers so they get used to the new possibilities of .NET? An NAV developer should know something about databases, table relations, business logic and so on, a .NET developer lives in a complete different world. That maybe will cause some problems in future. I'm sure this will not happen in every situation, because there are some specialists that are able to live in both worlds. But there is a certain risk if you hire an NAV developer that your solution doesn't consider all possibilities of new technology and on the other hand if you hire a .NET developer that not all NAV database issues are covered.

From my point of view this question also implies the following: What will be the future of NAV developers? You know SQL becomes a bigger topic in future, web services as well, form and report design is going to change, maybe cloud computing and network could be an issue,... I think maybe it's possible that we won't have a single NAV developer but several for different parts of NAV. And that leads me to another question: From a companies point of view, how should someone decide which way to go with his traditional NAV developers? I mean NAV is not a development tool, it's an ERP system with some possibilities in development. So, you need someone who knows about the business logic, not so much about the programming language (that's easy to learn for someone who's able to program). That means, should you qualify your current developers in terms of .NET or should you hire .NET developers and teach them how to understand and implement business logic?

You see, I have some doubts about the right way and there're plenty of open questions about the future. So, I want to hear what you guys think about that...

Interesting topic. I wasn't at that session, so I didn't hear that question, but...

I am writing a series of blogs for the Dynamics community
https://community.dynamics.com/product/ ... ystem.aspx

And in preparation for the next one I was pulling some ideas from an old blog I wrote but never published exactly about this topic. Not so much a coincidence, as this being quite a hot topic. Of course I need to focus on my blog right now, but in summary.

I don't see an issue here. Right now the shortage of Skilled NAV developers is probably even more acute than when we had the huge shortage between 1996 and 1999. Its nearly impossible to find skilled NAV people right now, but since there are literally 100,000 of .NET and C# etc programmers, it seems only logical that those skilled in NAV need to stay where they are and if anything hone their NAV skills rather than learning new stuff.

Keep in mind that one of the highest paid techies out there is the Developer skilled in DB400/Cobol/REXX etc.

I see what you mean. But you also know that even in this shortage it's difficult to find a skilled NAV developer. Some guy typed some lines of C/AL and calls hisself an NAV developer, you know what I mean. In future you have to choose between a lot more candidates and I'm sure there're also many that are not skilled in the way you want them to be. That doesn't make things easier.

And it's true that DB400 developers are best paid (doh, while my studies I should had gone that way ). But their workload could become less and less because those systems become less. Ok, those developers also become less and maybe it's still enough work for a lifetime, but may not in a certain region or branch. I don't know exactly, but I know it would be hard for a DB400 developer aged 55 or maybe 60 for example to change his whole life and maybe he won't get a new position if he needs to. I mean I wouldn't want to keep my developers in a position where they maybe will have problems in future to find another job.

Right, that topic in some parts points also into the same direction.

I do not see any problem here. Main thing is that you will need more developers for different topics.

*NAV Developer doing the business logic inside NAV, preparing webservices for outside
*C# or any other developer to create the application consuming the webservices (or creating webservices consumed within NAV), creating addins for RTC...

And if you have these two, the C# developer could help NAVdeveloper when he need to use .NET interop to do something using .NET assemblies...

For C# developer is not problem to learn the C/AL but it is problem to learn the business logic. For NAV developer it is not problem to understand logic but learn the C# (.NET). Put both into a bowl, mix, and you have team solving different things on both sides...

Of course, if NAV developer is accessible to learning, he will learn .NET quickly enough to be able to create some addins and application himself.

Hardest is to try teach NAV developers to .NET without having some .NET developer on site.

For sure, Kamil, that is one possible way for future. But think about a small development department. We have to buy Visual Studio, hire at least one new .NET developer and integrate him into our team. And all the traditional NAV developers maybe think about what will happen if the new .NET developer has learned to code C/AL.

Additionally that means that NAV development in future will be more some kind of team development rather than a one man show. That means you have to change the way how your department works. All the different development processes have to be reviewed.

All of that will be a massive change for a small development department.

We have been looking for a skilled NAV developer to join me.
Since we could not find one, management decided to hire a junior and transfer him in.
I am kind of dreading it because it is so easy to cause major problems with custom code.

The move to using more .net could make the shortage of good NAV developers worse, since I believe a good ERP understanding plus a good functional NAV understanding are requirements for a good NAV developer.
Then in addition to that you need the C/AL skills, the SQL knowledge and skills, and now the .net.

The days when the process was one-man-show are away a long time. And if somebody missed that, than sorry, but the train is already moving, it will be hard to catch it.

Long before NAV 2009 was released were announced, that there will be more C#, more reporting, SQL support only etc. It is more than 3 years now. If somebody noticed it now...

That processes in partners companies must be changed - definitely yes, just because RTC instead classic, you need different processes than before. There are new tools, new ways how to solve different things etc. To install NST you need to understand how the SPNs works, thus you need knowledge from administration, to be able to use SQL you need knowledge from SQL administration etc. But all this is known long before all this, you have the Statement of directions document. Why everybody is starting to solve that just now?

Of course, you are right. I didn't want to say that it should be a one man show or that a one man show is a proper way of working. I just wanted to point out that smaller development departments maybe will have to change their team structure. Or at least find a reliable and highly available way of how to analyse, modify and display business processes and business data based on the up-to-date technical possibilities. How do you get to this point and what is the best way to get there? That's not easy, especially if you have to consider your given budget.

First of all you can't base your team building on some rumors that are in the market. E.g. there're now some rumors that in future NAV and Sharepoint will merge somehow. Should I now hire a Sharepoint specialist to be prepared if this maybe becomes true in some years? And what if plans change during the years? I mean that is not an option and I would never base my long range decisions on rumors or something that is not official.
Second point is that some informations are only available for partners. So, if you are an end-user sometimes it takes a little while to get some news. And after you get it you have to understand it and classify the consequences. Afterwards you have to make a decision in your department, create a proposal for your board, consider it in your budget and HR planning and so on and so on. You see sometimes decisions at an end-user aren't as fast as they are at a partner.
But you're right, the preparation in terms of this topic could had gone much faster. But I'm sure you also know sometimes (espacially) end-users eschew (inconvenient) decisions and postpone them several times.
I believe that many end-users at the moment are not prepared for that (switch to RTC, modify business processes, change the way how development change requests should be worked out, think of the possibilities of new technology, ...). So, I don't want to complain about the situation, I'm pretty sure we will accomplish it. But I think it's even worth to discuss it and see what other think about it.

How is this any different than a normal upgrade? Yes, there are more inputs into the final decision, but that's what the partner is for, to guide the end user to the best possible solution.



Again, I guess I don't see how this is different than normal. I think that's one of the main functions of an IT / Programming department manager: to do their best to stay ahead of the game, anticipate changes in the software they will be supporting for the company, and take appropriate steps. Whether that be hiring new people or sending existing people to training, those are the decisions the manager should always be making based on the current conditions (budget, work load, etc).

Obviously the NAV world is changing, and those who continue to work with it will need to change too, but I don't see how it should drastically change your process or structure. Then again I'm just a developer Never had anyone report to me or had to really make those kinds of decisions.

Do you mean we should ask our partner about how we should qualify our employees and how we should do our HR planning? Ok, from one point of view they maybe had the same questions in their company some time ago as well. But on the other hand I think they won't give any reliable consultancy to this. Maybe a guess or a hint how they did it, but there are many differences between a partner and an end-user, so I don't know if that would work.

Absolutly! You're totally right.

Not at all, a partner shouldn't tell the customer how to run their company. They should educate the customer on the product, and then the customer makes informed decisions about the type of staff they need / if they need to hire new people or train existing ones.

For example, if NAV ended up moving entirely to the .NET platform, I would like to think that a customer with in house NAV development staff would not upgrade to it without determining their developers' .NET experience. You have to build on what you have now and plan for the future at the same time. This is one of the extra inputs I meant. It's important to not just consider functionality, but consider the software as a whole. Customers usually have years to plan for these types of things, that's why I don't think it really changes anything. NAV versions are supported at least two at a time, and have extended support back another version. So that's 6 to 8 years you can be on a supported product without a change to your staff. Plenty of time to plan ahead.

I know that was a bit garbled, but hopefully you get what I mean.

Yeah, I think I understand where you are coming from.

Keep in mind that you have to do all of this while you have to keep your normal business running. As explained earlier take two years away where you just gather information, then another two years where you think about and plan your strategy and maybe another two years where you search for a proper new developer or educate your existing ones. That means you have between zero and two years where you could decide how to go on. And that doesn't include unexpected team changes, company politics, trouble in operating business, etc.

The new version of NAV allows for much better integration with web services.
However the report development is still not good.
We are looking for a much improved report development process and features in version 7, so the question is - upgrade to 2009R2 which looks very solid or wait for version 7 - which may be buggy until the first or second service pack.
Since only a few outsiders have been able to work with NAV 7, this is a big unknown.
From a functional point of view (not development) is this really the equivalent of a service pack or is it a major release with a lot of greatly revised functional features with the potential of a lot of problems in the first release.

Each time when somebody ask me if go to NAV 2009 and than on "7" or just wait for "7" I am answering: "NAV 2009 is last version with support for both technologies. If zou do not do the "Big bang" of RTC, it is only way to go through NAV 2009. Even when going in way of "Big bang", it is better to go through 2009 because you can still in some point find out that you need to solve something with classic client. If you will wait for "7", you can miss the time for the transition between classic client and RTC. And what you prepare for NAV 2009 RTC, will be used in "7" without problem, thus no "double investment"."