Yet there are an awful lot of companies out there who fail to use a solid database platform or who have marketers that can't articulate what their database is (and don’t understand why I care.)
There are even software execs who delude themself their "just another database" is something far more than it is.
When I'm looking at software it's not just a matter of a business evaluating its functionality. Obviously, function is important. You don’t want a financial package that can’t raise purchase orders, for example.
However, there are also many technical considerations any company beyond a certain size will be looking at too.
Just four I keep in mind are how well the package slots into an enterprise architecture, how easily we can extract ad-hoc data on demand, how well it scales and how well it operates over a wide area network - if at all.
Often times these four matters come down to the database technology used. Let's be frank, a lot of software houses are really letting themselves down here.
Sometimes it's a matter of skimping on costs. You see this when the software stores its data on a file share. That's a low cost development solution which accordingly yields low quality returns.
Software that saves to a file share is a never-ending source of problems. You have to map a drive letter which sounds insignificant but keep in mind these are a finite resource.
You will have problems with drives failing to map from time to time, as happens for varying reasons, and which result in help desk trouble tickets, application unavailability and more.
Additionally, a file share is going to give dismal performance over a WAN. As soon as you want to run the app in two different offices your users will complain it’s too slow. You may get forced into terminal services whether that suits your plan or not. Sometimes the app won't even perform satisfactorily on the local area network!
This isn’t my only gripe. What about databases from non-database companies?
Make no mistake; there are good reasons why a terminal environment may suit your business. What I don't like, though, is being forced into it by bad software. Frankly, I think if a program requires running terminally to perform adequately then it's a badly written program.
Of course, not all bad software is just because the company was cheap.
Another problematic database comes in where the vendor has clearly had money to burn and opted to write a proprietary database system instead of focusing time and effort (including debugging time!) on the core product.
Now, I don't want to stifle innovation here but unless your line of business is databases, don't go writing a database.
In these instances, data is almost certain to be impenetrable and most certainly there won't be any ODBC driver or support for external querying, analysis and reporting tools.
MicrOpay Payroll Manager is one such example. Another is WorkDesk and even MYOB falls into this category, although it does provide limited ODBC functions for a fee.
I expect to be able to write any custom report, or perform any analysis or trending on our data. If a product restricts this then I have a real problem with it.
Whether a software vendor is big or small, budget constrained or not, they're doing me no favours when they neglect to use a database or they think it smart to write one.
They also don't help themself when the marketing people can't articulate their own product.
This can come in the form of WorkDesk responding to my queries by saying "We use a database written in C" - which conveys no useful information at all. The same when GEMMA refers to its use of an "SQL data file."
There are even multitudes of marketeers spruiking about their "SQL" database. This is similarly a term devoid of meaning. Do they mean SQL Server? MySQL? Heck, any database that can accept SQL queries be it ANSI compliant or not?
I must give praise to MYOB who are currently re-engineering their product to use SQL Server but even then their early literature referred to “SQL.NET” which was a similarly meaningless term. Happily, after I challenged them, they now talk about a .NET application using an SQL Server back-end database.
This immediately communicates to corporations the technical landscape required and also silently conveys the higher capabilities you can reliably expect.
Other companies learned this lesson too, with MicrOpay Meridian and Quickbooks now having SQL Server versions, to their customers' satisfaction, and no doubt to a decreased development cost of their own.
The lesson is simple: if you’re a software house and databases aren’t your core business then don’t write one! Secondly, if you sell software, make sure you know the name of your technology. The customers do care.