Basic Application Design for System Adminstration

				
From a system administrator's point of view there are some basic design
conventions that have nothing to do with user interface but far 
more to do with how the application is installed, administered, 
upgraded, managed and secured.
In no particular order the following are things that an application
should at least look at.
On real operating systems most applications should have their own 
administrator user account that 'owns' the application files. 
Do not stuff the application into OS files or other application
file systems. A common method is to have an application hierarchy 
of directories with all files needed under that hierarchy. Do not
scatter files belonging to an application all over many file systems.
Let the system administrators designate the application directory path,
do not constrain to a specific place in the file system.
Let the system administrators designate the application owner,
do not constrain to a specific naming space, but a recommendation
is not a bad thing.
This administrative user could be the user that runs the application 
if it is something like an ERP or database or license manager or service. 
The user that runs the application should not be root or superuser,
which usually indicates severe design flaws, especially in security.
The user privileges needed to run the application should be 
follow the principle of "least privilege", in other words be the 
lowest level possible.
Have a method of installing different versions so as not to crush
previous installations.
Have a method of to remove the application without destroying the 
underlying systems. 
Home grown license managers, databases, backup schemes, cryptography,
etc should be avoided. Use a standard APIs or products that do these 
things better than you ever could. Concentrate on what the application
should do well, not on a better password scheme, (unless that is the
application.)
And realize this application is not be the only thing running on 
the OS. Too many applications force systems to do unconventional 
things for just this one application. When several more applications
show up with the same premise they just don't play well together.