Articles   Home

Basic Application Design for System Administration

As a system administrator I have seen many "off the shelf" applications and in house applications that have basic administration problems. Some are just plain bad design that make the application hard to administer.

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.

Have a method of turning on and off the damn thing and include a script to do so. Patching or fixing a program is hard if it can only run 24x7 and if it fails, it fails ugly and leaves a mess.

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.