Optimizing Software Configurations:

System Requirements or Just Guidelines?


Once upon a time, when you needed a computer, you simply went out and bought one. The configurations were generic: Hard drive, DOS and a monitor (color, if you were lucky). Today’s software, however, requires a growing list of requirements: Hard disk space, operating system levels, a particular service pack, even specific video cards. Any deviation from the required configuration can have dire consequences. Let me explain.

What Do You Need?
It is really very easy to determine what kind of system you need for your applications. People in the CAD / CAM / CAE marketplace, those with Novell Netware (come on you old timers, admit it) and now with Microsoft Operating Systems and Applications know that the software comes with a set of requirements. You will note that the software says ‘requirements.’ This is not like a frozen entrée you buy at the grocery store that provides you with a ‘serving suggestion;’ it is a requirement. All too often, we have a tendency to try and ‘get by’ with what we have. It's human nature for most people to try and save a buck here or there. Depending on the circumstances, having a configuration that does not meet the requirements can have monetary and productivity consequences.

Network Operating Systems
When dealing with network operating systems, people often try to take a PC that is not good enough to run on the desktop and relegate that to server status. The results for anyone who has tried this are disastrous. The entire network, file saving, copying, database applications, printing, plotting, etc. are compromised by the weak link in the chain. The same thing happens when you install a network operating system on a PC that was not designed or certified as a server: Performance issues occur that cannot be identified,  and satisfaction and confidence in the machine drops.

Operating Systems
Operating systems have a list of requirements too. They specify the minimum RAM, disk space and processor to run then with success. I know what you're saying; you have a machine that was rated lower than the requirements and you got it to load. OK, you've got me there. I did a load of Windows XP Professional on a 486/DX4 100 MHz machine just to prove I could. It did install, but simply moving the mouse resulted in 100 percent processor utilization in the task manager. Did it run? No! The system did not have the capability from a hardware standpoint to do what the software required. Seems like we have a theme going here, huh?

Applications
Applications these days come in a wide variety, as compared to the old days of a work processor, simple database and spreadsheets. There are applications to handle accounting, applications for burning CD and DVD media, CAD / CAM / CAE applications, and others for document management, video authoring, web design and, heck, even for games. They all have one thing in common: The vendors who wrote the software came up with a list. This list is not a secret; vendors put it on the packaging, the CD or DVD media, even their web pages. This list has the minimum requirements to successfully run their software with the least acceptable level of performance. Why do they do it? Because they wrote the software and their marketing groups know the minimum levels of hardware and software configuration that will allow their customers to:
1) Load the software
2) Run the software
3) Be satisfied enough with the software that they are a return buyer for upgrades

It is really just that simple. At this point, VAR’s enter the picture, in the case of Autodesk software, for example. The way we add value to the software / hardware purchase is to optimize the configuration of the software so your purchase:
1) Performs with peak efficiency
2) Minimizes problems and possible data corruption
3) Builds trust between the VAR and the customer

System Requirements or Just Guidelines
One of my favorite lines from the movie Pirates of the Caribbean was when Captain Barbosa refers to the Pirate's Code as, "more what you'd call 'guidelines' than actual rules." If system requirements followed these "guidelines," tech support and help desk jobs would be few and far between. The fact is, those system requirements are just the starting point for being able to run and support those applications. They are the baseline, the foundation, the watershed from which the software can be configured and troubleshooting, if required can begin. When those requirements are not followed, the customer is not done a service in making something work, but a disservice. Workarounds for software and configuration tweaks are designed for operating software within a baseline set of specifications. When applied to machines that do not meet the requirements of operating system, service packs, patches, drivers or hardware, the results can be unpredictable. The costs of getting your system configured properly are small with respect to lost productivity, data corruption or even data loss that can be suffered by not following the system requirements.

Not all Inventor Certified Cards are created equal
Anyone who has been using Autodesk software since the 1990’s will remember that the software has always liked some video cards better than others. Show of hands, again-anyone remember the Prometheus Video Cards, with the TSENG Chipset? Be honest, I'm not the only one, right? Well, with Inventor, Autodesk took that from "like" to certification, and they added the phrase about Full CAD functionality. Autodesk says that ‘Some graphics vendors produce graphics cards for both game/business use and CAD use. 3D CAD and other top-end software products demand much more from the graphics card hardware and its driver than game or business applications’. Remember when you look at the card certifications on the Autodesk site to look at the key below, shown on each page for card certifications. In this case, green circles are what you want to see; anything else spells trouble!

	The lightning bolt signifies that this certification is newer than the version of Autodesk Inventor® that was selected. An update is required. A prompt will display for the user to click and download. With an older version of Autodesk Inventor®, it is always okay to use a newer certification.
	The green symbol means the card and driver fully meet the graphics system requirements of Autodesk Inventor®.
	The yellow symbol means the card or driver generally meet the graphics system requirements of Autodesk Inventor®, but that some important information is available.
	The red symbol means the card driver does not meet the graphics system requirements of Autodesk Inventor®. The driver will continue to run using Microsoft GDI software emulation.

Be aware that running the software with a video card not certified by Autodesk will limit your options when the software crashes. Remember, these are system requirements, not guidelines, and anyone who tells you differently is setting you up for a problem down the road.

How can I get more information on this subject?
If you have support services through Hagerman and would like more information on this subject, just ask. We may have additional suggestions you should think about in the long term when dealing with machine configurations. We do our best to provide you with honest, competent solutions that will optimize your purchase and help you get the most productivity out of your people. If you have questions or comments about this article, contact me (JohnBoline@hagerman.com).
 

All product names / logos, company names / logos are copyrights of their respective holders. John Boline is an MCSE, CNE and a member of the Network Professional Association. The content herein is often based on late-breaking events. Much of the material is based on information from sources that are believed to be reliable. Hagerman & Company, Inc. disclaims all warranties as to the ultimate accuracy or completeness of the information. Hagerman & Company, Inc. and its employees shall have no liability for errors, omissions or inadequacies in the information contained within this article or for any interpretations thereof. The recommendations, positions and best practice policies outlined herein represent Hagerman & Company, Inc. initial analysis and therefore are subject to change as further information which may have bearing on these positions is made available. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice. Entire contents © 2005 Hagerman & Company, Inc. All rights reserved. Reproduction of this publication in any form without prior written permission is forbidden.