Get the CarFax Report for Microsoft Dynamics NAV ISV Software
I recently had to purchase a new car for my son. He’s 23 and had driven the same 1994 Nissan Altima I’d given him as a first car at 16. He drove it throughout high school and now into his senior year of college. But finally “Alti” took her last gulp of gas, let out her last fumes of exhaust, and we had no choice but to quickly find a replacement.
Please understand, when I say I had to purchase a “new car” for my son, I just mean one that we personally had not owned before. I believe the term the salesperson used was (clear throat) “pre-owned.”
Buying a used car can be a tough game! You have to somehow determine if you are getting all the information you need to make a good decision, or if something is lurking in the dark secrets of the car, waiting to attack your wallet in the years to come. Fortunately, we got the Carfax report and were able to tell that the shiny red Subaru Forester my son liked was perfect for him. It had low miles, had not been wrecked, rebuilt, or in a flood, and had been serviced regularly. That meant we could be assured that “Forest,” as he is now affectionately called, wasn’t going to be a money pit, requiring lots of mechanical work in the years to come.
The Carfax report was critical to my decision to purchase the vehicle. I don’t know anything when it comes to cars past the steering wheel and stereo! I can look under the hood all day, and all I see is black metal, grease, and hoses! Yet, being a NAV developer, I can “look under the hood” of a NAV 3rd Party Add-On and tell you the level of code quality fairly quickly.
Most often business professionals are faced with making software decisions based solely on a list of functional requirements. While there isn’t a “SoftwareFax” report for ISV Software to provide a level of confidence prior to making a decision, there are questions you can ask to determine the level of product quality and assure you are purchasing software that will bring a positive ROI.
Installation
A quality ISV product will have a simple installation path. Often driven by an external wizard or NAV page with questionnaire-style direction, the installation process should be so simple that documentation is either very short or non-existent. If it must be installed by your VAR, you need to know this ahead of time and include that in the cost of ownership. Some of the questions that can be asked are:
- What is the standard number of hours to implement the software?
- Who can implement the software?
- Are there external elements required for the software that are not in the purchase price?
- How will this software work within my environment (given it might be a CITRIX server, Virtual Machine, or Terminal Server farm with remote connections)?
- How many installs are currently in production on this version? (Warning: You do not want to be a lab rat for new software! Lab rats die a slow death!)
- What is the ratio of software support cases to installs for this package? A high ratio will mean that either the software has problems or the documentation is not effective for the average users. Either way, this can increase your cost of ownership.
Rollback
No one wants to have to turn off software when you’ve just purchased it. That’s like having a brand new car that you can’t drive! But in the event that it is required, how hard will it be to turn off the software application you have integrated to your database? In some applications, it’s as easy as unchecking a box on the setup page. In others, you reach the point of no return when you add the objects to the database.
Footprint
A quality ISV product will not embed code into standard NAV objects, but create “hooks” in the code to call functions from the product Codeunits. By having a smaller code footprint within the standard NAV objects, the cost of upgrading NAV, or installing hotfixes to NAV, is lessened.
Meets Standards
At this late date, the one thing we should not have to ask of credit card processing software is if it is PCI compliant. That is the standard for credit card processing, and not using those standards can place a merchant at risk of costly fines and breaches of security. SOAP standards, HIPAA guidelines, and many other standards regarding business and regulations should be addressed when reviewing software. Don’t be afraid to ask the question, “Is this software in compliance with government and business regulations?” If you have special customers, such as government agencies, you might have to participate in software audits occasionally to retain the customer. Lost business due to a failed software audit can dramatically increase your software cost of ownership.
Broken Functionality
I recently was introduced to an ISV package that repurposed the Global Dimension 2 field for a custom purpose, rather than just adding a field to each table that required this extra bit of data. This misuse of the standard NAV fields would have cost the client in that they would have lost one of the two core pieces of data available throughout NAV for financial analysis.
Ask the question, “Will I lose any standard functionality if I install this software?” Then you can make an educated decision related to the cost of the loss of functionality.
Clean Database Design
Another ISV package I recently dealt with in a NAV 2013 install gave me a big surprise when I was told that not all objects in the package should compile. Apparently some of the objects from the prior version used automation controls that would not work in NAV 2013. Yet, instead of removing the object from the code set, the objects using these automations were left in the code as unused global and local variables. Without the code in the database, the other objects would not compile. Yet, the objects could not compile themselves because they did not meet the requirements of NAV 2013 regarding automations, which cannot be OCX type. In my honest opinion, this is just lazy coding. It’s not that the few objects that sit idle in the database are harmful, but that the developers didn’t feel it was necessary to take the references out and remove the objects, giving the package a higher level of quality. What can I say? As a developer, objects that don’t compile really bother me!
Hotfix Path
Hotfixes should not be handled in a patchwork manner, as if repairing holes in an old quilt—one code fix here and one code fix there. A good ISV package will have a hotfix path, whereby each and every code correction is rolled into a packaged and numbered version of code that can be easily installed to the application. When an ISV chooses to repair software one issue at a time, without noting which came first, the repeatable success of installing the hotfixes is diminished. As any good NAV developer knows, modifying one object in the database out of sequence with others dependent upon it is the quickest way to have a very bad day!
Ask the question, “How are hotfixes delivered, and in what way can I know my software is fully up-to-date with your modifications?”
Does it REALLY Work?
Before buying Forest, we took him for a test drive, and I’m not talking about a slow Sunday drive, either! We drove him with the pedal to the metal and checked for smoke from the exhaust pipe. We tested the brakes, checked the lights, slammed the doors, listened to the engine, and kicked the tires. If you are seriously looking at an ISV product, don’t forget the test drive! Let your users lose on it! Pull out your list of functional requirements and find out just what it takes to accomplish each one. The question is, will the software get you down the road like riding in a limo, or will you be pushing it with more manual manipulations that you care to invest?
But don’t stop there! The software should mesh with NAV completely. Review the data. Check reports. Complete the process within the standard NAV functions to assure the system is integrated as a whole into the process. For example, if you are importing bank transactions to a Cash Journal, go ahead and apply them, check customer statements, look at the Customer Ledger Entries, and run your Aged Accounts Receivable report.
Software packages are a lot like cars. Your business will depend on the software on a daily basis. Don’t short-cut the process by only checking to see if it meets your functional requirements. Take a look under the hood, and ask lots of questions.