Have you been in this situation?
Your business has been running on a nice customized database program for about ten years that someone developed for you. The program fits tightly with how the business operates. It was developed by someone in the past who had a full time job and did the work during his off-time for a good price. You just replaced a computer with a newly bought one, with the latest version of Windows. Now nobody can install or run the program on the new computer. The guy who developed the program can't be reached for support. He went on to other things and can't be bothered with your problem.
Now what?
Time to go looking for someone who can fix the problem. You're not sure what language the program was written in, and you don't know anything about its database, except you think it's called something like, XYZ. You ask your computer support person if she knows anything about it. No - she can't figure it out. She doesn't do databases. You ask around, but nobody you contact knows how to deal with it. It's some old system nobody uses anymore or has never heard of.
If you search long enough you should be able to find someone who can provide some sort of solution, so you'll be able to have new computers when you need them. This problem could happen again. But it could have been avoided, and can be avoided in the future.
Was the decision to use a custom program instead of a commercial one the issue? No. Although commercial software is really good and can meet a lot of the needs of a business, it's often not enough. Each business and organization has unique processes. Many times the uniqueness calls for some customization. When you decide it would be beneficial to have a custom application you should follow these guidelines in order to avoid being left in the lurch some day.
To control costs you should use a consultant who will use a standard, popular, rapid development platform. The following are current good platforms for putting together custom database programs quickly and economically:
Microsoft Access
This is the desktop version. You would need a license or copy of Access for each computer the custom program will run unless the consultant uses the Runtime Engine. The Runtime Engine will let you run the program free on any computer. An Access program will only run in Windows. There's no Mac version. An alternative to Access for the desktop is using Office 365 with Sharepoint in the cloud. Microsoft has tried to make the pricing for this arrangement attractive to all businesses. However, development costs for a custom database program are likely to be higher than for the desktop.
OpenOffice Base
This is also for a desktop version of a program. It's free, open-source. So you can run the program on any computer for free. The OpenOffice suite is available for Windows, Mac, and Linux.
FileMaker Pro
This is a robust platform that allows the creation of applications to run on desktops, through the web, and on mobile devices. This solution is not free. You'll want to use a server with this. Filemaker offers a cloud server alternative.
Alpha Anywhere
This is another platform that allows a developer to create applications for desktops, web browsers, and mobile devlices It requires a server, and has a cost structure too.
For any of these platforms be sure that the agreement with the consultant gives you complete ownership of the program and data files. Also be sure that no matter what tool a consultant uses to create a program, that you have a copy of the source code. The source code is the form of the program in human-readable format. If the source code is unavailable, and you need another consultant to take over support it will be much more difficult to do anything with the program.
The above platforms are likely to be around for a while, and there is a large community of developers who have worked with them. This means that if your developer drops support you shouldn't have difficulty finding someone to step in and take over. However, things can change suddenly. One of these platforms could go out of style in the future. This means that as soon as your developer loses interest in being around to support you, you need to find a replacement ASAP. The replacement can let you know when the platform is losing poplularity, and when it's time to think about moving to a new platform before it's too late.
Friday, September 11, 2015
Monday, August 17, 2015
My Painful Experience with a Web Hosting Service
I want to share my experience and thoughts about having a website on a shared hosting account.
Several years ago I was looking for a hosting service to set up a website for my business. At the time there was already a large number of companies to choose from. I didn't do any real research. I just chose one of the first ones I came across. The name of the hosting company is Action Web Hosting, and I've stayed with them for a long time because I've experienced really great uptime with my site. I learned later that Action Web Hosting is a reseller for GoDaddy, meaning the computers running websites are run by GoDaddy.
Another thing that kept me with Action Web Hosting was their 24/7 phone support. I've never experienced any bad wait times. However, not all has been rosy. In the last couple of years I've experienced frustration getting technical issues resolved.
My most recent incident began on August 4, 2015. On that date I received a preformatted email from Action Web Hosting congratulating me on an update to my hosting account. The email indicated that I had a new server for my website and I could start using it. I had never requested a change to my service, and had never received a heads-up from them that any change was going to happen. Nervously, I checked my site to be sure it was still showing up. I discovered that pages that connect to a database on the site could no longer connect to it. I immediately called customer support. The rep informed me that my site had been moved to a new server because the one it was on was now too old and unsupported. The rep had no idea how to correct the database problem, so she conferred with someone else. I was then advised to try making a change in the connection information on my pages. The suggested change had no effect, so the rep escalated the ticket.
As of August 14, 2015, the issue was still unresolved. On August 10 I received an email from customer support stating the issue was resolved. But it wasn't, so I contacted customer support again on August 11. I was told the problem was still being addressed and I should get a resolution in about three hours. On August 15, when the issue remained, I once again called customer support. The rep told me to try deleting my database and then recreating it. He acted as though this wasn't really his problem, and I got the impression from his attitude that I was wasting technicians' time working on a problem they couldn't figure out. The rep claimed I was the only customer experiencing this issue. Finally, on August 15 I gave up and tried deleting the database and replacing it with a new one. After I did that the connection worked for the new database.
Understandably, I started looking for another hosting service. As I said before, this wasn't the only issue I had experienced with customer support, but I don't have time to go into those issues now. I can say that I know a little something about website technology because I'm a database developer who has created web pages and was the one who set up my business site and database. When I contact customer support I often feel as though I'm talking to an idiot. But that's a harsh judgment. Customer support reps don't have the resources at hand to address these issues quickly, and they are not technicians - they're more like customer relations people.
In researching other hosting services I've found lists of recommended ones based on number of customer complaints vs. praises. My experience with Action Web Hosting (GoDaddy) and my research into other hosting options have left me with the following thoughts.
First - no matter how highly ranked a web hoster is, you can find customer complaints about support. Plenty of diatribes can be found related to broken sites caused by the hoster and the frustration of dealing with clueless customer support reps. In addition to my own problems, I've witnessed a couple of my web developer colleagues' struggling with incompetent support reps when their clients' sites ran into trouble. One client's site was down for at least two weeks. They finally moved to another hoster. The troublesome web hoster was IX Web Hosting, by the way.
Second - customer support is not really technical support. When you contact support you're probably just getting a customer-relations-and-sales rep. These people are cut off from the technicians, or have poor communications with them. With Action Web Hosting, it's as if the support reps are even more in the dark about the situation than I am.
Third - things are great only when things don't go wrong. When things do go wrong, and the fault is on the hoster's end, the support reps want to blame you for any issue you report. They like to suggest that you've done something incorrect in a configuration or script file, when in fact there's nothing incorrect and the site was working for months without a glitch with the same configuration and scripts. It can be nearly impossible to get though to anybody there that there's a problem with the server they need to troubleshoot.
So I've decided on this course of action:
I'm going to look for another hosting company which is high on the ranking lists, and is not a reseller. Then I'm going to copy my website onto the new hosting account. I'm not going to end my account with Action Web Hosting. That's because I intend to maintain two duplicate websites in case one runs into trouble, and because the GoDaddy servers do indeed stay up and running most of the time. Finally, I'm going to set up a failover service that will redirect traffic to one of my duplicate sites whenever the other one encounters a problem.
In summary, my solution is to use redundancy. I'm going to assume that sooner or later a hosting service will fail me, no matter how high its ranking or how reliable it's been for me in the past. Fortunately my site's issue with my database was not a critical one this time. But I want to ensure future glitches won't hurt my business when my site's uninterrupted functionality is critical.
Saturday, February 21, 2015
Steps to Successfully Changing Your Business Software Part IV: Implementation
You've selected and purchased your new software, or signed up to a cloud-based application. Now it's time to implement it.
There are two major challenges to implementing new software. One is change management, and the other is data migration. The new software should be as close as possible to what you documented when you were analyzing your needs during the business analysis phase. However, the new software's design might require you to make some changes in your processes that you wouldn't have made otherwise. If you involved all your employees in the design and selection phases, change management will be easier because they will have had the opportunity to participate in decisions about the new system and be much more likely to be positive about making changes. If you intend to import data from your old system into the new one you'll need to plan how to do it. Data migration is often not given the consideration it should when implementing new software. Lack of planning and appreciation for the difficulty of this task leads to frustration with getting a new system running and working right.
You should follow these guidelines when implementing a new software system:
- First, you should expect, and accept, that things will go wrong. If you expect that unplanned problems will crop up you'll be much better prepared to deal with them. Almost any new system implementation requires more work and time than can be foreseen.
- Be careful about setting deadlines for implementation. Don't base deadlines on arbitrary dates and wishful thinking. It's good to have a ballpark date for final implementation, but you should be ready to adjust this.
- Avoid the temptation to do a complete cutover from the old system to the new all at once. This places your business at risk. You can manage risk by following a staged plan for transition from the old system to the new.
- Include a testing phase in your plan. You should schedule testing the new software with sample data to be sure it works as expected. Testing can reveal problems you can get corrected before committing to the new system. Break up the testing for vaious parts of the software. Be sure you do thorough testing. Don't assume everything will work without a hitch in the new software.
- Don't try to migrate all the data from the old system before testing the new system. You should import only enough sample data to test certain parts of the new software at a time. Importing small sets of data will reveal issues with data migration which you can address when doing a complete migration plan.
- Be sure to include data cleanup in your data migration plan. Usually the data in an old system lacks consistency, which makes it difficult to import correctly into another system. For example, a data field in the old system may have been used to record phone numbers at one time, but then used to record emails at other times. But the new system has separate fields for phone numbers and emails. Or perhaps the old system had a field for a phone number which could be entered in any format (with or without parentheses and dashes, with or without long-distance prefixes), but the new system uses phone number fields that require a certain format and number of digits. You'll need to identify data that's entered inconsistently or incorrectly in the old system and get it corrected before trying to import it. This might require hiring data entry temp help.
In some cases a business can adopt a new software system without migrating any data from the old system. In such a case you'd be using two separate systems without the need for any sort of data synchronization. In most cases a business will require running two systems in parallel with some kind of data synchronization until the old system can be dropped. In the latter case it would be wise to plan for a phased transition from the old system to the new one. This means using only parts of the new system in stages. This helps to mitigate risk, and affords a fall-back strategy in case issues are uncovered with the new system. By keeping the old system running and up to date you can fall back to using the old system for everything until issues uncovered in the new system are resolved.
Keeping data in sync between two systems can be a challenge, and must be carefully planned. It might require doing double data entry, or running data synchronization software, or a combination of the two.
Of course, there should also be time planned for training on the new system. But training should not be used as a substitute for early employee involvement in the software selection process and testing it to be sure there aren't issues you didn't anticipate.
There are two major challenges to implementing new software. One is change management, and the other is data migration. The new software should be as close as possible to what you documented when you were analyzing your needs during the business analysis phase. However, the new software's design might require you to make some changes in your processes that you wouldn't have made otherwise. If you involved all your employees in the design and selection phases, change management will be easier because they will have had the opportunity to participate in decisions about the new system and be much more likely to be positive about making changes. If you intend to import data from your old system into the new one you'll need to plan how to do it. Data migration is often not given the consideration it should when implementing new software. Lack of planning and appreciation for the difficulty of this task leads to frustration with getting a new system running and working right.
You should follow these guidelines when implementing a new software system:
- First, you should expect, and accept, that things will go wrong. If you expect that unplanned problems will crop up you'll be much better prepared to deal with them. Almost any new system implementation requires more work and time than can be foreseen.
- Be careful about setting deadlines for implementation. Don't base deadlines on arbitrary dates and wishful thinking. It's good to have a ballpark date for final implementation, but you should be ready to adjust this.
- Avoid the temptation to do a complete cutover from the old system to the new all at once. This places your business at risk. You can manage risk by following a staged plan for transition from the old system to the new.
- Include a testing phase in your plan. You should schedule testing the new software with sample data to be sure it works as expected. Testing can reveal problems you can get corrected before committing to the new system. Break up the testing for vaious parts of the software. Be sure you do thorough testing. Don't assume everything will work without a hitch in the new software.
- Don't try to migrate all the data from the old system before testing the new system. You should import only enough sample data to test certain parts of the new software at a time. Importing small sets of data will reveal issues with data migration which you can address when doing a complete migration plan.
- Be sure to include data cleanup in your data migration plan. Usually the data in an old system lacks consistency, which makes it difficult to import correctly into another system. For example, a data field in the old system may have been used to record phone numbers at one time, but then used to record emails at other times. But the new system has separate fields for phone numbers and emails. Or perhaps the old system had a field for a phone number which could be entered in any format (with or without parentheses and dashes, with or without long-distance prefixes), but the new system uses phone number fields that require a certain format and number of digits. You'll need to identify data that's entered inconsistently or incorrectly in the old system and get it corrected before trying to import it. This might require hiring data entry temp help.
In some cases a business can adopt a new software system without migrating any data from the old system. In such a case you'd be using two separate systems without the need for any sort of data synchronization. In most cases a business will require running two systems in parallel with some kind of data synchronization until the old system can be dropped. In the latter case it would be wise to plan for a phased transition from the old system to the new one. This means using only parts of the new system in stages. This helps to mitigate risk, and affords a fall-back strategy in case issues are uncovered with the new system. By keeping the old system running and up to date you can fall back to using the old system for everything until issues uncovered in the new system are resolved.
Keeping data in sync between two systems can be a challenge, and must be carefully planned. It might require doing double data entry, or running data synchronization software, or a combination of the two.
Of course, there should also be time planned for training on the new system. But training should not be used as a substitute for early employee involvement in the software selection process and testing it to be sure there aren't issues you didn't anticipate.
Sunday, February 15, 2015
Steps to Successfully Changing Your Business Software Part III: Software Selection
Before you've reached the stage of selecting your software, you've thought through and documented what you're looking for. Therefore, you should already know what you want. When weighing choices you should follow the guidelines below.
Rely on your own needs analysis. You should have done a thorough job developing a design for your ideal system. Software salespersons don't know your business, and they can't do a better job than you in the selection process. They only know about their own software, and can't know how well it will meet your needs.
Avoid basing your selection decision on canned demos from salespersons. Ask if you can get demos based on your own specifications. The pre-developed demos that salespersons present make their software look great, but they almost never tell you anything about how well it will work for you.
Make sure you understand the software you are looking at. If anything is confusing, that's a warning sign. Don't assume training is the answer. You should be selecting the software that comes closest to your ideal design concepts.
Take advantage of free trials. You should never purchase any software, whether cloud or installable, without first giving it a test drive, if possible. A lot of software comes with a free trial.
Be sure to weigh the pros and cons between cloud software and software installed in-house.
Check the scalability of the software to see if it can keep up with possible changes and growth in your business.
Carefully check the support agreement. Is 24/7 phone support available? Will any user support involve a cost?
Try to estimate the true cost of ownership for a package you're looking at. If in-house, how often will you have to upgrade? How long is a given version supported?
Find out what integration capabilities the software has. Does it have an API? An API - or application programming interface - allows anyone with the right programming skills to create custom applications that can interact with, and augment, the software. Does it have good features for exporting and importing data from various sources? Does it have built-in integration with such popular office software as Outlook, Excel, and Quickbooks? If you don't have your own programming expert to help you evaluate these capabilities you should seek a consultant who can do this.
How much will implementation cost? Do you plan to migrate data from your existing system into the new one? How big a job will this be, and how much could it cost? Moving data into a new system is often overlooked and grossly underestimated in the selection process. Don't rely on the salespersons for the new software to advise you on this. They will want to minimize the difficulty, of course. If you don't have someone working for you who can evaluate this, you should seek the advice of a consultant.
Avoid basing your selection on what other similar businesses use. Remember every business has unique processes. Even if another company is in the same industry as yours, it will likely be using a given software package differently from the way you would. The software might be a good fit for the other company, but not yours. Stick to the ideal design you developed when you analyzed and documented your needs.
While you shouldn't base your selection on what similar businesses use, you should get references or find others who are using a package you are looking at. Ask them about their customer satisfaction experience.
Always consider combining more than one piece of software. Any single package has strengths and limitations. People often look for a single package that will do everything. It's possible to select two or three inexpensive pieces of software, with different sets of functions, and integrate them. This way you take advantage of the strengths of each piece. This combination can be much more powerful than relying on a single piece of software that performs some functions well, but is weak or lacking in others.
Avoid brand new software or a brand new version that hasn't stood the test of time.
For cloud solutions figure on implementing your own data backup scheme. Also consider what to do during outages. Always assume you'll have outages.
Rely on your own needs analysis. You should have done a thorough job developing a design for your ideal system. Software salespersons don't know your business, and they can't do a better job than you in the selection process. They only know about their own software, and can't know how well it will meet your needs.
Avoid basing your selection decision on canned demos from salespersons. Ask if you can get demos based on your own specifications. The pre-developed demos that salespersons present make their software look great, but they almost never tell you anything about how well it will work for you.
Make sure you understand the software you are looking at. If anything is confusing, that's a warning sign. Don't assume training is the answer. You should be selecting the software that comes closest to your ideal design concepts.
Take advantage of free trials. You should never purchase any software, whether cloud or installable, without first giving it a test drive, if possible. A lot of software comes with a free trial.
Be sure to weigh the pros and cons between cloud software and software installed in-house.
Check the scalability of the software to see if it can keep up with possible changes and growth in your business.
Carefully check the support agreement. Is 24/7 phone support available? Will any user support involve a cost?
Try to estimate the true cost of ownership for a package you're looking at. If in-house, how often will you have to upgrade? How long is a given version supported?
Find out what integration capabilities the software has. Does it have an API? An API - or application programming interface - allows anyone with the right programming skills to create custom applications that can interact with, and augment, the software. Does it have good features for exporting and importing data from various sources? Does it have built-in integration with such popular office software as Outlook, Excel, and Quickbooks? If you don't have your own programming expert to help you evaluate these capabilities you should seek a consultant who can do this.
How much will implementation cost? Do you plan to migrate data from your existing system into the new one? How big a job will this be, and how much could it cost? Moving data into a new system is often overlooked and grossly underestimated in the selection process. Don't rely on the salespersons for the new software to advise you on this. They will want to minimize the difficulty, of course. If you don't have someone working for you who can evaluate this, you should seek the advice of a consultant.
Avoid basing your selection on what other similar businesses use. Remember every business has unique processes. Even if another company is in the same industry as yours, it will likely be using a given software package differently from the way you would. The software might be a good fit for the other company, but not yours. Stick to the ideal design you developed when you analyzed and documented your needs.
While you shouldn't base your selection on what similar businesses use, you should get references or find others who are using a package you are looking at. Ask them about their customer satisfaction experience.
Always consider combining more than one piece of software. Any single package has strengths and limitations. People often look for a single package that will do everything. It's possible to select two or three inexpensive pieces of software, with different sets of functions, and integrate them. This way you take advantage of the strengths of each piece. This combination can be much more powerful than relying on a single piece of software that performs some functions well, but is weak or lacking in others.
Avoid brand new software or a brand new version that hasn't stood the test of time.
For cloud solutions figure on implementing your own data backup scheme. Also consider what to do during outages. Always assume you'll have outages.