As many will know, I'm a Software Developer by trade - the visual part of Navigator was written by myself and my father 20+ years ago.
As we approach our 25th Anniversary, it's interesting to look back to see how software development has changed - in particular with third party interfaces.
Much of the work with third party interfaces used to be very customised. With data being structured in non consistent ways and being communicated using a variety of techniques. This means that every interface was complex because we had to discover not only how the business process worked, but also how information being communicated was to be transferred before custom writing software.
Many developments involved interfacing with software that was running "in-house" on a users desktop - eg a Parts Catalogue
These days, the world has changed. Developers now speak a common language write across the world. Data structures are standardised and in particular the documentation relating to the whole interface process is also standardised.
This makes the technical part of the software process very simple.
For example, I got involved with a software interface with a third party this week. The third party in question was MG and the interface was their new Lead Management Hub. The business process is pretty simple "pick up the leads every few minutes and present to the sales team" and "send lead updates back".
20 years ago, this would had inevitably required several meetings to discuss data formats, technical interfaces etc.
The documentation supplied was all in what is now a standard format.
20 years ago, I would have allocated maybe a week or two of development time to writing, testing and internally documenting this interface followed by extensive customer and franchise testing.
These days, the standardisation is much simpler.
Much of this is because Navigator has standardised "hooks" written for this sort of interface so all we need to do is plumb into these. Another massive benefit of modern software solutions!
I decided that this was a straightforward project and I would build it myself.
I received the test-credentials for interfacing as a "test" dealer on Friday morning, and sat down on Fri afternoon to write the interface. 2 hours later, it was done and initial testing complete. A further hour to write the documentation to go with it...
Documentation is an important part of the process. We generally write 4 sets of documentation :-
- Documentation of the Code itself - so that if anyone comes across the routine later it describes in English what it does
- Documentation of the whole internal solution - this lists all the new software routine names, any data supporting it and describes how it hooks into the application
- Installation Documentation - how do we deliver this to a customer
- User Documentation - How does the end-user use this.
In a project like this, documentation takes longer than the software! The actual software was less than 100 line of code. Because the interfaces in Navigator are standard and already well tested, testing is simply the process of checking that information appears on screen in the right place and that updates are sent back as required.
Documentation is also the part of the process which most developers like the least! Me included! But having developed software for 35+ years and often having to maintain software written many years before, by somebody else- good documentation is critical.
Meanwhile, the advances and standardisation of the software development interfaces makes software development quicker and easier. This translates into a lower cost of development, a faster time to market (the MG Leads interface will be with a customer in the next few weeks) and ultimately a lower cost to the end-user.
Find out whether Navigator is a good fit for your dealership. Spend 30 mins with one of our Consultants in a no pressure environment. Click the button to book a Zoom Call
Book a Discovery Call
.jpg)
