Application architecture (long post - sorry)

Ernst Noch enoch at gmx.net
Sun Jan 1 12:20:39 CET 2006


limeydrink at hotmail.com wrote:
> Hi all,
> 
> I want to create a mobile field worker data solution.
> 
> Let me explain...
> 
> I work for a company that has some software used by call takers to
> enter information into a database about faults with electrical
> appliances they manufacture, sell to customers, and then provide
> maintenance contracts for.
> 
> The company has a number of field workers (growing number) servicing
> these appliances, and information about the faults and customer
> locations is fed to them by printing off job sheets from the call
> taking system and then either faxing them to the engineers or the
> engineers drop in to the office and collect them.
> 
> There are lots of problems with this, such as lost job information,
> incomplete forms, incorrect non validated data, the cost of printing
> off job sheets and also the engineers having to collect, regular phone
> calls to the engineers to update them on call informtion, and then the
> fact that all this data then has to be inputted back into another
> system manully.
> 
> Basically I want to create a means of getting this data to them
> electronically.
> 
> I know there are a few companies who could provide this solution but
> they are very expensive and possibly overkill at the moment, we could
> start developing our own basic system then it can grow over time.

Just one advise from my personal experience:

Don't build it yourself.

This part of your company seems to be growing, and a number of 60 field 
engineers is already considerable.
So, processes will change, managers will ask for specific KPIs, the need 
will come up to dispatch engineers based on their location/skillset etc. 
etc.
You might run into technical problems with the client appliances 
(compability) if you don't do extensive testing.
So, soon a commercial application might not be overkill anymore, but you 
already have a Big Ball of Mud sitting there.
( http://www.laputan.org/mud/mud.html#PiecemealGrowth )

All in all you should at least do a careful cost comparison between 
commercial off-the-shelf software (COTS) and inhouse development for
the next 3 to 5 years.
Don't understimate testing and training costs and the change of your 
business.

I could see two alternatives:
1. Buy a COTS package which has the big additional benefit of being 
implemented for some tried and tested processes, so that your company 
doesn't have to reeinvent their processes from scratch (it worked with 
SAP, didn't it ;) )
2. Go the super cheap route, like buying a blackberry package from a 
local mobile provider and send the jobs to the engineers via email.
The neat thing is that it pushes out the mails to the clients.
Maybe there are also some ready made packages to implement some forms on 
the blackberry's email client.
That way, you have the alternative of cheaply learning how things go in 
practice, and refine the requirements.










More information about the Python-list mailing list