NAV development tools: better/easier than AX?

ianb

I'm not a techie, so be gentle with me...

I am assisting a client in the big choice between NAV and AX.

We notice that estimates of effort to provide system mods / enhancements for AX are typically higher than those for NAV (average 40-50% more days).

Can anybody provide the reasons why this might true?

I understand there to be a "layered" architecture to AX, to which NAV will converge under project Green. Is this reflected in that greater effort? Is it a premium worth paying to obtain the "future proofing" of buying into AX now?

Looking forward to the discussion !

Ian B

David_Singleton

This is a very interesting topic. Also one that is not often discussed.

I think most people will agree that you can do a lot more with X++ than you can with CAL. Though most people tend to forget that X++ is a much LOWER level language than CAL. Also even more importantly, X++ and Axapta was designed and thought of as a development environment. CAL and Navision were thought of and designed as an ERP system. I don't mean that you can't develop in CAL, nor that Axpta is not an ERP pacakage, but the emphasis is different.

X++ give you access to the lowest levels of the system code, CAL has more distinct limits. These limits mean that more protection can be put in place, and thus there is less work involved on the part of the developer. But these are just technical issues.

What it comes down to in the end is client expectation, and managing that expectation. Expectation Management, (or at least the failure to do so), is one of the major reasons for ERP failure at the Go-Live point.

When Navision Financial first hit the market, it introduced a whole new level of customize-ability to the ERP market. At that time there was nothing even close to what Navision offered. Concorde didn't make it, and they realized that they needed a different approach to the way it had been going for the past 5-8 years.

So was born X++, and the idea that the development environment would not be tied to the application, but would be a super powerful development language in its own right.

And what this did is change expectations. Clients now realize that X++ can do anything, so they want everything. Sales people go out and show three or four fancy commands, and then after the system is sold the client expects this to be simple. Then we add to this layers of code, which means each user can have their own customized system with in a system, so now there is no need to train, we will just redesign the system around the users mistakes. basically in Navision, you reach a point where you say, NO that really does not make sense, lets look at the business process and work out a better solution.

So really what it all comes down to is the ability to manage the clients needs and don't let them drive the system out of control.

In terms of NAV vs AX, then generally if you are really not sure which system they need, then NAV is probably better for them. If they need Axapta then the requirements will make it pretty obvious that they need it.

PS the 40-50% Higher no of development hours surprises me some what, I would have expected it to be far more.

Miklos_Hollender

It's not very straightforward to tell which one is better for development. I would say C/AL is very classically a business system development environment - something that's optimized for data entry, transaction processing etc. X++ is something more - it's fully object-oriented and so on and so on. X++ requires a real developer while in C/AL application consultants can slowly turn into developers. Or from the other way around - developers can concentrate on understanding the business, because the coding is simple. So C/AL development can be quicker because there is no such a big overhead for communication and specifications. C/AL is more suitable for an Agile Development approach where instead of writing design documents you just iteratively hack up something until it works and then clean it up. And Agile is usually a much better approach than anything else.

However, C/AL is really for classical business systems. Data entry, data processing, no fancy stuff like OLAP cubes.

However, on the other hand, the biggest problem I see with Axapta / X++ that you design the user interface on the logical level. So you just tell it which menu item comes after which and which field goes on which tab and it will do the positioning. This is very clean, yes, but sometimes when users want just that button to be put just there in just that size and color then I think you can't do this. I don't think you could design a usable POS touchscreen for example in X++. And the worst are reports. If you use logical positioning, it's OK. But if you move around the controls with the mouse it will look like crap.

Warning, my information is from Axapta 2.5/3.0 - quite old.

Harish

Hi David,

Just my .02 cents over your following comment -

Then we add to this layers of code, which means each user can have their own customized system with in a system, so now there is no need to train, we will just redesign the system around the users mistakes. basically in Navision, you reach a point where you say, NO that really does not make sense, lets look at the business process and work out a better solution.

Ax indeed allows you to have minor tweaks (for example positioning of fields in a form on user level provided user had necessary rights) but not to the extent of redesigning the sytem around users mistakes. Perhaps I might be wrong but in almost all the installations that I worked so far, in cases like this it was the business process that got altered.

Ian -
just curious - which version of Ax are you currently looking at?

Regards,

jesam

C/AL is more suitable for an Agile Development approach where instead of writing design documents you just iteratively hack up something until it works and then clean it up.

I think a lot of people would be offenden by this way of describing Agile Development. It's first and foremost a state of mind.
In second place, it 's a matter of the IDE. As we all know, Navision has nothing worthy of the name IDE. Without a good IDE that supports refactoring and full compilation of a project, Agile development is hell.
The language plays only a minor role in the Agility of a system, but as far as it does, I'd even go as far as stating that an old non-OO language like C/AL is not very much suited for Agile development as it tends to produce long (multi-page long) complex procedures that try to do a gazilion things instead of the small fine-grained objects that only perform one task that we find in typical modern OO systems.

And Agile is usually a much better approach than anything else.

With that I agree.

ianb

David Singleton wrote:

PS the 40-50% Higher no of development hours surprises me some what, I would have expected it to be far more.

Thanks all of you for the wisdom so far.

I am an Agility enthusiast, and would not like it to become a stick with which to beat either app. I too suspect that Agility lies in the mindset on the project rather than the choice of environment.

It's v4.0 AX that we are being sold, and I should be most interested in further comparative quotes / benchmark evidence in relative development effort.

Ian B

David_Singleton

ianb wrote:

David Singleton wrote:

PS the 40-50% Higher no of development hours surprises me some what, I would have expected it to be far more.

Thanks all of you for the wisdom so far.

I am an Agility enthusiast, and would not like it to become a stick with which to beat either app. I too suspect that Agility lies in the mindset on the project rather than the choice of environment.

It's v4.0 AX that we are being sold, and I should be most interested in further comparative quotes / benchmark evidence in relative development effort.

Ian B

Also keep in mind that these are both excellent product, and in the end you probably won't go wrong with either.

in terms of Agile Design, you are obviously aware that that really has nothing to do with the development environment, but the mind set of the designers. And experience counts here.

There are many NAN developers with 10+ years experience out there. Obviously with Axapta that experience does not yet exist, so that will also be something to factor in. This is because X++really is a totally different concept to XAL. C/SIDE on the other hand is very similar to AL, so the knowledge carries on. Also the next generation product that is planned for release this year, leverages all that experience again, so if you can wait a while, then this Third Generation of Navision may be your answer.

DenSter

One more thing to consider is that good AX resources are very rare so you should be prepared to pay top dollar for those resources. You can also consider the idea to offshore development, but make sure you find yourself an experienced partner (for instance Tectura has over 100 of the finest Axapta people working out of one office in Delhi).

David_Singleton

DenSter wrote:

One more thing to consider is that good AX resources are very rare so you should be prepared to pay top dollar for those resources. ...

That's what I was saying, but I was trying not to emphasize that experienced Axapta developers get paid a lot more than Navision. :whistle: :-$

DenSter

I was trying to avoid the issue that because they do, some of them are in it for the money only.

<edit><disclaimer>some NAV people are in it for the money also</disclaimer></edit>

Alex_Chow

Good ol' supply and demand.

Also, keep in mind that if you do not like your AX partner, there are only a few to choose from in your geographical area, if any.

ianb

DenSter wrote:

One more thing to consider is that good AX resources are very rare so you should be prepared to pay top dollar for those resources. quote]

Now... here's funny thing. The day rates we are getting quoted / negotiating with NAV resellers are 10%-15 % greater than those for (onshore) AX ones.

Ian B

DenSter

oh wow that is funny, I always thought AX work was more expensive. You're going to need a lot more of it though, NAV is much more efficient to develop in, so you might end up spending more anyway. Plus, you can also do NAV development offshore.

Alex_Chow

There's another thread somewhere on this forum regarding offshore development. In summary, MOST of the time, you get what you pay for.

Nonetheless, AX developers tend to charge more than NAV developers. There are exceptions of course, but it's uncommon.

Miklos_Hollender

There is something else - development costs aren't only based on the development tools but also

A) how many standard functionality it offers
how stable are they
C) how simple are they - how easy to understand and change

Axapta wins on A). It provides really nice things like f.e. route optimalization for manufacturing. Navision wins clearly on - it doesn't do much but what it does is really solid. Not the fancy stuff like reservations/tracking f.e. there are sometimes problems with those, but the basics, like having correct inventory quantities per locations and being able to track it back to documents etc. it's really solid. Navision wins on C) - once one grasps the master data - document - journal - entry concept it's quite easy to grasp what's going on.

Miklos_Hollender

Jesam,

on agile - well, it really depends on how we define it. I define Agile not really as a full-blown methodology but simply an approach - having iterations instead of big designs. From my point of view Agile is simply the acceptance of the fact that users can't define requirements correctly until they have *something* to play with. Actually I don't like the current trend of trying to stiffen Agile into a defined methodology with defined iteration cycles and refactoring rules and so on. The whole point is flexibility - a methodology of non-methodology but organic growth.

As for refactoring, I rather like the functional than the OO approach and although Navision is not suitable to fully functional programming (not first-class functions, no closures) at least we try to have many small functions that usually try to not modify anything but to return values. That way they can be recombined differently when the requirements change.

David_Singleton

DenSter wrote:

oh wow that is funny, I always thought AX work was more expensive. You're going to need a lot more of it though, NAV is much more efficient to develop in, so you might end up spending more anyway. Plus, you can also do NAV development offshore.

Not that strange really. Its all about market perception, and the UK market perceives these two products differently to the US.

Imagine you sell both products, then you would want to sell Axapta if possible, since is more of an unknown, and thus you will for sure be able to bill more hours, and more importantly the client will not have as good an opportunity to switch NSCs if something goes wrong.

Of course all the NAV partners will be saying "yes but Axapta costs more" so by selling Axapta services at a lower rate than Navision, they have a better chance of closing the deal, and locking in the customer.

Most cities in the US have at most 3-5 NSCs, in London there are a lot, AND an NSC with an office in London, Manchester and Edinburgh could deliver basically anywhere in GB, giving buyers a lot of competition. So even if the client goes for Navision, it doesn't mean they buy from the NSC that "sold" Navision.

Back to rates. This is the biggest difference. The UK has this rather odd habit of billing Days instead of hours. Theoretically this evolved because of the horrendous traffic, that meant you could never rally set a valid appointment time unless you started at 6am in the morning. In my experience, daily rates are bad both for the NSC AND for the client, but lets not go there. Anyway, daily rates are much easier to play with than Hourly, and to be honest, I know from my developer days, that I get a lot more work done per hour in an 8 hour day then in a 15 hour day.

So don't look at the difference in Rates, especially if they are daily rates. Look at the whole cost of the implementation. but be aware that if a partner of any kind is offering discounted rates, then either they are heading towards bankruptcy, or they are new and need your business. A partner has to pay salaries, train its people, have office space sales teams management etc. Those costs MUST be paid somewhere in the total project cost.

David_Singleton

Miklos Hollender wrote:

Jesam,

on agile - well, it really depends on how we define it. I define Agile not really as a full-blown methodology but simply an approach - having iterations instead of big designs. From my point of view Agile is simply the acceptance of the fact that users can't define requirements correctly until they have *something* to play with. Actually I don't like the current trend of trying to stiffen Agile into a defined methodology with defined iteration cycles and refactoring rules and so on. The whole point is flexibility - a methodology of non-methodology but organic growth

....

=D> well said.

ianb

ianb wrote:

Is it a premium worth paying to obtain the "future proofing" of buying into AX now?

So... I have learned that the difference between C/AL as a 4GL and X++ as a "pure" low-level OO language probably accounts for a lot of the perceived "AX development premium".

It has been put to me elsewhere that there is a payback, namely in the realms of ease of

- maintenance
- integration
- extension

ie AX is said to be waay easier to tweak, post-implementation, than NAV.

Is anybody going to challenge this view?

Secondly: that the extent of the "premium" is design-dependent. Certain object and features are less person-hour efficient than others, whcih will account for the variability in early estimated on both sides of the fence.

IanB

ianb

...oh yes and - thirdly - the "layers" of AX mean that there are no nasty ambiguities about the IPR of modifications, when the vendor is perhaps also the ISV of a vertical add-in.

Makes it easier to migrate partners and/or upgrade...

IanB

kashperuk

DenSter wrote:

I was trying to avoid the issue that because they do, some of them are in it for the money only.

Now I don't want to agree on this one.
I think most of the people who started working with DAX simply fall in love with MorphX. I know I did. And a lot of the people I know.

If they were for the money only, they would switch to something else, like SAP.

DenSter

kashperuk wrote:

DenSter wrote:

I was trying to avoid the issue that because they do, some of them are in it for the money only.

Now I don't want to agree on this one.
I think most of the people who started working with DAX simply fall in love with MorphX. I know I did. And a lot of the people I know.

If they were for the money only, they would switch to something else, like SAP.

That's why I wanted to avid that topic. The good ones are always in it for the right reasons, regardless of the product that they work with. But, in my experience, I have seen more AX people that are more interested in their own financial gain than the customer's wellbeing. I have to add there that my experience with AX resource is probably not very extensive compared to some other people, and maybe it is a lot better now than it was 4-5 year ago

One other thing you should check out is if AX resources are cheaper than NAV resources for any particular NSC, then you might want to ask them if they offshore their development.