jump to navigation

Security 01/29/2013

Posted by TBoehm30 in Uncategorized.
Tags: , ,













ERP Access – Getting Things Done 03/26/2012

Posted by TBoehm30 in Database.
Tags: , , , ,
1 comment so far















How close is your software vendor? 10/12/2011

Posted by TBoehm30 in Software.
Tags: , , , , , ,
1 comment so far












What is a bug? 04/02/2010

Posted by TBoehm30 in Software.
Tags: , , , ,

What is a bug? Of course, I am talking about a software bug, and not the 6 legged variety. To me a bug is any quirk of the program that I find should and could be done better. That puts the entire definition in my hands. I am the one that gets to define what is and isn’t a bug. As the user, I get a say in how I think the program should work.

I don’t always get my way. Recently, I got into an argument over some software that wasn’t performing according to my needs. The problem was minor, the workaround was easy, and the reason for its existence was obvious. That doesn’t change the fact that this was a bug (see the definition above). The software vendor took offense at my criticism and explained that it was not a bug and that the underlying code is, in fact, written correctly.

Wikipedia defines a bug as:


By this definition I have to admit that he was right. Their system was designed by the software company to meet their requirements. Since he insists that the result meets their requirements, then there is no error, flaw, mistake, failure or fault.

So who is right?
This argument goes on all the time. Users often incorrectly think that something is a bug in all kinds of situations:
It is their own fault (PEBKAC).
They haven’t read the manual and therefore don’t understand the software.
They want the software to run better, and suggest an improvement.
They need new functionality in addition to what they’ve got.
They don’t like the output of the system, but they don’t have a way to change it.
The system isn’t as intuitive as it could or should be.
(Yes, some of these overlap; No it is not a complete list. Feel free to add to it in the comments; I’ll add them later if they are good enough.)

The software vendor can reply to almost any “bug” report that it fits into one of the above categories. Unless the bug is something obvious like “the computer crashes when I enter a 10 digit number in the text box prompting me for a phone number”; the vendor can come back to deny that it is a bug.

If the vendor actually does call something a “bug”, then they will be forced to fix it. If they can deny that is a bug then the cost of a fix can be avoided or at least delayed. Vendors have several choices in arguing against calling something a “bug”. They can say that it is not reproducible, so it must have been the computer. They need more information because they can’t reproduce in on their own systems.

My favorite is the SWAD excuse – System Works As Designed. This means that what I am seeing, not liking, and getting frustrated with, is not actually a bug. It means that the software programmers deliberately set out to annoy me. It means that they don’t really care that a simple peon like me has an opinion about their gigantic company. They don’t believe that I could have an inkling of an idea about how hard it is to write enterprise software; how difficult it is to please everybody.

The problem is that I do have a technical background. I do have an idea how hard it is to write large software programs. I do know the difference between a bug, a design flaw, a feature request, and a user problem. I’ve been on both sides of this argument. I’ve been the one who explained that the system works as designed because I designed it. I’ve been the one that denied the bug until it was reproduced in front of my face. I’ve tested software to report bugs. I’ve also used plenty of good and bad software.

If a user was asking for their accounting software to automatically search the internet for recipes, that would be a new feature. It is completely understandable for software vendors to reject those ideas as being too big a project to take on, and too costly an investment.

However, if the software allows the user to re-order the dropdown lists in the system, but ignores the text for some of those lists, that is a bug. Why is it up to the user to know that he shouldn’t use the re-ordering functionality on some lists? The software should either prevent the user from making the change, or allow the change and evaluate the choice in the dropdown correctly and dynamically. The latter suggestion would be my preference. It would make the software more intuitive, easier to customize, and better for everyone.

Reading this, you might get the impression that I recently found a bug in some software, but was rejected by the vendor. I like my software to be usable, intuitive, consistent, and complete. Most of the time software we use works well. Sometimes we have issues with it; and sometimes we report our issues.

All I really want is to be acknowledged. I want the vendor to either explain to me how I can accomplish what I am trying to do with a workaround, or agree to put this bug on a list that will eventually be fixed. I have no illusion that my little problem will ever be important enough to be completed. I don’t expect immediate results. All I want is for the people I am working with to recognize that a bug is defined by the user, and work to resolve the issue, not ignore it. How about you?

Do you need multiple databases? 02/19/2010

Posted by TBoehm30 in Database.
Tags: , , , ,

Should you setup multiple databases for the company? No matter what your desire, you will always wind up with multiple databases. Whether they are backup databases, training databases or development databases, they will be needed.

The answer, however, is NO. You do not need multiple production databases for your company.

Using multiple database has its allure because it allows you to separate your data. You might have internal security issues which require separation of data and access. You might have reporting requirements which demand information to be segregated. You might have data issues which cannot exist on the same database. The easy, quick, answer is multiple databases.

There are too many problems with creating multiple databases. Let’s walk through an example that demonstrates the problems with the easy solution. You work at a company that wants a new ERP system for its 3 subsidiaries (it could be any database software – CRM, accounting, manufacturing, etc.). You want to make sure that each subsidiary doesn’t see any data from any of the others. You don’t want them poaching customers, or gathering data about the entire company.

You need a system that will work the same for everyone, but protect your security as well. You want to roll up accounting into corporate from the subsidiaries and have visibility from the top down. Multiple databases sounds ideal for that purpose.

Your company plans on creating or buying more subsidiaries in the future. Your plan for each new subsidiary is simple: Bring up a new database. As an added incentive, your subsidiaries use similar IDs for their data and would have to make significant culture changes if all their IDs had to change. [Think about a customer Id. If they don’t share data, then each of the 3 subsidiaries need a different Id for the same customer.]

Talk to the software vendor. Do you need to purchase extra licenses because of the extra instances of the software? Will they charge more for upgrades when it is not a single project? Will you have to replicate all customizations 3 or 4 times? Will you need extra hardware to handle the different databases? Can they exist on the same server or even the same instance of the database server?

Next look at your needs at corporate. You want visibility from the top which means logging into multiple databases. Are your executives savvy enough to handle that? Will they get confused logging into multiple databases? Is your IT staff savvy enough to handle the extra load? They will have to support all of them – that might mean simple password requests on 4 systems, or data inconsistencies from corporate reports.

Finally, look to the future. Could you combine your purchasing department to get better volume discounts for shared suppliers? How would you do that on multiple databases? How about centralizing the sales department? Could that be done with the setup you’ve chosen? The same goes for most of the functions that could be centralized, but are not today.

How do you solve these problems? Yes, there is extra work in that. You’ve got to setup security around each subsidiary so they don’t see other’s data. You’ve got to figure out a scheme for setting up IDs such as customer IDs and Supplier IDs that won’t conflict and won’t cause too much disruption. You’ve got to create a plan to bring up new subsidiaries within the existing system.

Again, talk to the vendor. You are going to save money on the software by only going with a single integrated system. You should need fewer licenses, and less expensive hardware. Your single database will be able to consolidate corporate data quickly and effectively.

Your IT department will be relieved from all the extra work. They will only need to support one system. They will only need to create 1 set of reports; even if they have extra security around them. They will have one system to have problems with and solve. There will never be integration problems between the systems. They’ll never have incompatible parameters, or global indicators that don’t match.

Talk to your executives and find out what information they need at their fingertips. Can you create real-time dashboards across multiple databases? Can you provide real-time reports on cash, inventory value, A/R, A/P, etc.? Do they need to export data from the system, and would that work if it was exporting from multiple systems?

The bottom line is that a single database makes sense for a single company. Don’t let the easy answer to tough questions change your outlook. It might take more work to set it up, but in the long run, it’s worth it. As we all know by now, it’s a global world out there and Technology makes it happen.