Specifying Required Resources

In general, a required resource is something that someone is going to require you to utilize in your project. Specific resources might be required by the internetworking department (the router and WAN circuit folks), by the telecommunications people, by a corporate standard (Unix/Oracle, Windows 2000/SQL Server), by the IT department, or even by the narrow field that you' re operating in. If your project will help out the manufacturing arm of your company with a new app, you may not have much choice in the type of software that you can buy.

There may be other required resources in a project. Companies that are heavily invested in Oracle, for example, will require that you use it for the database back end. This might create problems if you ' re thinking of buying some canned software that requires SQL Server. If the company ' s requirement is rigid enough, you' l l have to either figure out whether the product you want can talk to Oracle or find a different product.

Some companies require that a given network operating system (NOS) be utilized, such as Unix or Windows 2000 Server. You' l l have to plan your project accordingly. Protocols are often overlooked and can create a lot of problems during the development of a project. If, for example, you buy a software product that uses a proprietary protocol, you may have to get the router folks involved to open up ports on the firewall (something they' l l be very reticent to do) or to allow this protocol to traverse the network. It may be that a "required resource" is a standards-based product that doesn' t do anything strange or hazardous with certain protocols.

You may find that you' re not able to go out and buy servers—the company has a specific asset pool, and the IT department knows which servers are going to host which applications. You might be told that your application is going to run on Server A, for example. This can create tremendous problems if your new app is a resource hog and IT personnel not associated with the project underestimated your deliverable' s tenacious appetite for server resources. I ' ve seen, over and over again, emergency decisions made for new server hardware because an app that was supposed to run on an existing server didn ' t play well with others or over-utilized the server' s resources.

WAN circuitry is something else that hides behind the scenes at project formulation time. You may have an integrated services digital network (ISEN) circuit running from Campus A to Campus B, for example, at 128 Mb and, not knowing any differently, your team assumes that this bandwidth will be more than adequate for you new app. Then the project delivers the new app, the bandwidth shoots up to 80 percent utilization 100 percent of the time that users are on, and the complaints just keep a-comin' into the help desk. Had you raised the red flag on this problem, the project would have cost more because it would have included a WAN circuit upgrade—but in the long run, it would ' ve been much more successful.

Note Most internetworkers strive for a max of 30 percent utilization on any given circuit, though they tolerate spikes to between 80 and 100 percent for short times.

Was this article helpful?

0 0

Post a comment