The scope of Utility Programs is very narrow and usually quite "vertical" in nature.
Utilities are simple programs, often designed for a single purpose, and sometimes for a single use. These types of programs often do not have a user interface at all. They frequently
operate as background tasks or system services. That means they do their job without ever being seen by users of the software.
Even though they are not seen by users, utility programs are very often at the very core of what keeps a very large, integrated system working. Even large client-server systems often
rely upon a host of small utility programs that run in the background keeping things running smoothly.
Other utilities do have user interfaces, but they tend to be very simple and of a very narrow scope; a sinlge form, with a single button (often labeled simply "Go").
Another category of utility is that which does have a user interface - sometimes a very comprehensive interface - and yet it may fall into the category of "utility" because it's scope
is very narrow and limited to a very specific purpuse or task. My dPingMaxx utility is an example:
For all it's complexity, it still fulfills just one primary objective: charting ping times.
The main difference between a System Integration Module and a Utility program is generally in the complexity or the amount of data that it must process.
Another differenece is that Utilities are generally developed by third parties after the fact, to do things that the developers of the large system failed to include or foresee. For
instance, one of the most common uses of utility programs is to fix or workaround bugs in a system until a permanent fix is afforded.
Time to develop a utility program is dependent upon the complexity of the task, but is usually measured in tens of hours.