A discussion about the technology
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:
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:
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:
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.
- Which language (or languages) is your product written
- Is the product a 16-bit, 32-bit, or 64-bit application?
- Which database (or databases) does your product operate
- Is source code available?
- What formal measures do you take to test and debug
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”.
Accounting Software Technology