A discussion about the technology behind
an accounting system or ERP solution

By J. Carlton Collins, CPA

 

The Importance of Evaluating the Underlying Technology

It has been my experience that far too many companies select and purchase accounting software without having a clue about the product’s underlying technology. Even today DOS-based applications written in Cobol continue to sell at record-breaking levels. I believe that the root cause of this madness is that many companies focus their evaluations on features, features, features – and little else. It seems that as long as the product has a given set of features, it doesn’t matter what the underlying technology consists of. It could be a system written in FORTRAN using a VisiCalc database and running on an original Nintendo box, and many people would still purchase the product as long as it has a few obscure features that they feel are important to their company.

Why is this important? Let’s think about this logically. Technology changes very rapidly – you already know that. Many current technologies will be obsolete in just a few years, or in some cases, just a few months. Old technologies are not made obsolete by “new technologies”, they are made obsolete by “improved technologies”. What I mean is newer technologies are better technologies that offer more power, more functionality, more capabilities. Eventually newer technologies overshadow older technologies to monumental degrees.

Look at it this way. Most older accounting software solutions contain far more lines of complex code compared to a similar product developed with more current technologies. In 1995, Gary Harpst of Solomon Software excitedly showed me their latest Solomon IV product that was written in Microsoft Visual Basic. Gary touted how Solomon was able to develop an extensive solution with just 300,000 lines of code compared to 15 million lines of Cobol code used to develop the older Real World product line. Since then Solomon has increased its lines of code more than five-fold – but it is still lean and mean compared to other Cobol based products. Consider for a moment how much faster a company could review or debug a product, or add functionality to product that contains dramatically fewer lines of code. All other factors being equal, surely the product with equal power but dramatically fewer lines of code will have a brighter and stronger future ahead – right?

To learn a little about the various programming languages in use today, please refer to my personal notes on Programming Languages here:

http://www.accountingsoftwareadvisor.com/topics/programinglang.htm

When evaluating the underlying technology of a product, it is also important to inquire about the product testing effort put forward by the accounting software publisher. You can find out why I think this is so important here: 

http://www.accountingsoftwareadvisor.com/topics/testing.htm

It is also important to find out whether the application is a 16-bit, 32-Bit, 64-Bit, or 128-Bit application. To learn what it means to be a 32-bit application, I’ve explained it in simple terms here:

http://www.accountingsoftwareadvisor.com/topics/32bit.htm

When it comes to a product’s underlying technology, there are many facets to consider. To help make sure that you cover all of the appropriate bases, presented below are a list of the questions you should ask when evaluating a product’s underlying technology. 

1. Which language (or languages) is your product written in?
2. Is the product a 16-bit, 32-bit, or 64-bit application?
3. Which database (or databases) does your product operate on?
4. Is source code available?
5. What formal measures do you take to test and debug your software?

Understanding Programming Language Tool Sets

Before a publisher uses a development language, they first develop a set of tools to compliment that language. For example, an accounting software product typically contains about 6,000 user screens. Each screen will probably have the same look and feel in terms of size, font, color, border, etc. In this case, the publisher develops a tool which automatically creates a new blank user screen with the click of a button. In this manner, the programmer does not have to recreate the wheel each time a new user screen is created. Instead, the programmer clicks a button and the predefined screen pops up, and the programmer modifies the screen from there.

It is important to understand this because publishers often give names to their respective tools sets. For example, Great Plains is written in “C”, but the tool set that Great Plains used to compliment “C” is called Dexterity. Some people falsely assume that Dexterity is the actual programming language, but it is not. It is merely a tool set that Great Plains developed to help programmers write code with greater efficiency and accuracy. Navision goes even further. Navision Attain is also written in “C”, but they refer to their programming language as C/SIDE. “C” being the programming language, and “SIDE” being their internally developed tool set plus an integrated database. Because Navision’s tool set is very extensive and integrates the database, the company claims that this makes the “product fast to implement, easy to customize, and simple to use and maintain”.