Close this search box.

NAV Development or an External Add-on?

Boundary Bend is Australia’s largest olive farmer and olive oil producer. Its brands include the household names, Cobram Estate and Red Island. In late 2015 Fenwick Software was engaged by Boundary Bend  as its Dynamics NAV partner, then in early 2016 a project was started to modernize its Olive Management System (OMS) using NAV as the platform.

The Olive Management System tracks the production of oil and is integral to Boundary Bend’s quality assurance and product traceability. In the future the OMS project may be the subject of a blog post but the focus of this post is the add-on software developed for use with Boundary Bend’s weighbridges.

The majority of the OMS functionality was developed in NAV. NAV is ideal for structured and linked data entry from different points in the production workflow, and for providing instant reports to assist with quality tracking. However, the team identified that the weighbridge component of OMS, where deliveries from the groves are recorded, could benefit from being developed outside NAV as an external add-on.

In software projects there are often alternative ways of solving a problem. It is important to consider and discuss the pros and cons before committing to a design.

In software projects there are often alternative ways of solving a problem. As an integration expert, I guided the team through the process of weighing up the factors that are important when considering the development of an external NAV add-on:

  • Ease of use for non-IT-skilled people – the weighbridge is run as ‘self-service’ by the truck drivers, who appreciate a large and simple user interface without unnecessary elements.
  • Offline operation (store-and-forward) – NAV requires constant network connection to servers, but unreliable network connectivity in the weighbridge kiosks was identified as a risk.
  • Integration to hardware (weighbridge scales and magnetic swipe card readers) – this can be achieved more simply in external software than in NAV.
  • Scope – NAV development is generally cheaper than external add-on development (as the NAV platform provides such a head start) so scope is important—is the add-on required to provide many features, or just one specific function?
  • Future maintainability – NAV modifications are generally more maintainable than external add-ons, and there is a large pool of NAV consultants available who can do this work.

On balance we decided to develop the weighbridge software as an external add-on. This has proven to be successful. A benefit of the off-line solution was demonstrated during a recent power outage. While the power was out overnight, deliveries continued to be recorded on the weighbridge terminals, with the data stored locally until the servers were available again and the data automatically released.

When functionality is required that is not provided by NAV, it is important to consider and debate the pros and cons of NAV development versus development of an external add-on.

Related Posts in ,