Re: PARADOX product life cycle
- From: Roy F <roydoc@xxxxxxxxxxxxxxxxx>
- Date: Sat, 25 Feb 2006 14:43:27 -0700
Hi Rodney,
>those doctors depending on the internet to
>conduct business, could not conduct business
>for several weeks after the hurricane we experienced.
If I remember correctly, in certain areas there wasn't any business of any type conducted for a few weeks. However those doctors would have the peace of mind knowing their records were safe and intact and once they could conduct business again all their records were ready and waiting. They would have certainly been millions of times better off than they were. You make some otherwise excellent points and indeed you have identified a critical issue.
>If the WAN or Internet is not available, then
>the system should be able to run in a "crippled mode"
>locally. This "crippled mode" would be one
>where business could continue to function with
>a reduced feature set and update the remote server
>automatically once an Internet connection
>was restored.
That is absolutely 100% correct and in my mind is a key issue to more widespread use and acceptance of this model. That is what I am working on now. I am rewriting my Paradox app for the web with this in mind. Unfortunately it is a complete rewrite and that makes it a very arduous process. It is almost like starting from scratch in many ways.
>Why not consider using a network storage device?
I really don't want to get into supporting hardware. And even though you can tell people not to mess with it, you never know what will happen or what someone will try to do. I did just get one for my network, and will set it up, try it out and see what I think.
>In addition... you should insist that your
>software is sold and installed
>ONLY through a network of trained
>value added vendors (VARS)
That's tough in my position as the variance in price for this type of software is huge and for a variety of reasons I am concentrating on the segment of the market that can't afford the big buck stuff. VARS would rather sell the high priced stuff for obvious reasons. That's another reason I like the internet based approach. You need many fewer technically saavy highly trained people as everything is administered centrally.
You certainly seemed to have hit the nail on the head with most of this analysis. It is a difficult market, but a real world problem waiting to be solved non the less.
Regards,
Roy F.
Rodney Wise wrote:
Roy,.
I agree with you... your scenario points out "real" issues. However... those doctors depending on the internet to conduct business, could not conduct business for several weeks after the hurricane we experienced. Internet, Telephone and Cable TV were all down in some cases for over a month.
I believe there needs to be a combination setup. Data specific to a Doctors operations needs to be maintained locally and the application software needs to maintain data synchronization and application updates seamlessly in the background. If the WAN or Internet is not available, then the system should be able to run in a "crippled mode" locally. This "crippled mode" would be one where business could continue to function with a reduced feature set and update the remote server automatically once an Internet connection was restored.
If a doctors office depends on your software for the core functions of their business.... and an on-site IT staff is not practical.... then the software and system must be as "self-healing" as possible.
Why not consider using a network storage device? One of the inexpensive Linux OS computers designed to operate as a network file server.... They are pretty dependable and can be serviced remotely.
In addition... you should insist that your software is sold and installed ONLY through a network of trained value added vendors (VARS).... All VARS who sell your solutions must successfully complete a training course (which you provide at a price)... During this training course, you instruct them how to install and maintain your software... you also provide a list of "Approved Hardware" and "Approved Hardware Configurations". These Vars become the endusers first level for service. The endusers never call you (the software developer)... only the Vars contact you if there is a problem they can't fix.... In which case, if the installed Hardware at the problem site is not approved.... or the Hardware configuration is not approved... you then tell your Var to correct it before you can provide any tech support. If a particular Var seems to violate this list of requirements often, then you drop them as a Var. By not following your instructions, they are giving your software a bad reputation... re-assign the enduser to another Var.
If a Doctor gets a hold of your software through some other means (the purchase of another Doctors business or an auction for instance), then you direct them to their local Var (if they call you). This prevents the semi tech savvy brother in-law from installing your software and creating problems for you and everyone else..
You can have complicated systems running in offices without a full time IT department... but they do need:
1. Software that is not finicky.
2. A "known system configuration".
3. A trained VAR to service them.
- References:
- PARADOX product life cycle
- From: rhug
- Re: PARADOX product life cycle
- From: Larry DiGiovanni
- Re: PARADOX product life cycle
- From: rhug
- Re: PARADOX product life cycle
- From: Rodney Wise
- Re: PARADOX product life cycle
- From: Larry DiGiovanni
- Re: PARADOX product life cycle
- From: janM
- Re: PARADOX product life cycle
- From: Roy F
- Re: PARADOX product life cycle
- From: Jean Friedberg
- Re: PARADOX product life cycle
- From: Rodney Wise
- Re: PARADOX product life cycle
- From: Roy F.
- Re: PARADOX product life cycle
- From: Rodney Wise
- PARADOX product life cycle
- Prev by Date: Re: PARADOX product life cycle
- Next by Date: Re: Adding calculated field to report
- Previous by thread: Re: PARADOX product life cycle
- Next by thread: Re: PARADOX product life cycle
- Index(es):
Relevant Pages
|