Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Checklist: Define requirements for new networking applications

In some companies, the in-house software development staff commonly develops and deploys applications outside the knowledge of the IT staff -- which can have dire consequences for the network. In this tip, Brien Posey explains why implementations go more smoothly when both departments work together. He also provides a checklist to share with developers.

As a network engineer, you would probably be rather upset if another department in your company purchased a software...

application for use on the department's desktops without checking with the IT department first. Your department would be expected to support an application that it did not approve. For all you know, the application could have serious compatibility problems, be riddled with bugs, or might even have been known to carry a spyware payload.

There are serious consequences to allowing anyone to install an application that has not been reviewed by the IT department. You would probably never let a department in your company purchase applications that you had not reviewed, and yet in some companies it is common practice for the in-house software development staff to develop and deploy applications without coordinating their activities with the network support staff.

More on this topic
All-in-One Research Guide: Network engineering

Applications running on workstations

For example, if the application is to be installed locally on users' workstations, then it will probably be up to you to make sure the workstations have adequate memory and hard disk space to run the newly developed application. Depending on the type of application, external components such as drivers or the Microsoft Database Engine may be required. These types of components can sometimes interfere with other things on the workstation if they are not implemented properly. Therefore, it would be beneficial to both the network administration staff and the development staff to outline the application's requirements before the application is actually developed.

Applications running on network servers

If the newly developed application is going to be run directly from a network server, there are other issues that must be addressed. For example, you'll have to decide which server will host the application. You will also have to estimate how much of an impact the application will have on the server's resources and how much bandwidth will be consumed by users accessing the application.

Application data storage and backup

Regardless of whether or not an application is going to run directly on a workstation or on a server, the data that is produced by the application needs to be one of your top considerations. Because it will be the responsibility of the administrative staff to store the data, you'll need to meet with the developers long before the application is ever deployed to discuss how much data the application is expected to generate. Only then will you be able to plan for long-term storage of this data.

Just as your department will be responsible for storing the data related to the new application, it is also going to be up to your department to ensure that the data is backed up on a regular basis. Depending on how much data the application is expected to produce, your current backup solution may or may not be adequate. You may find that you need to invest in a tape drive with a higher capacity, or possibly even in a backup solution that is specifically dedicated to the new application.

While you are considering the volume of data that the application will produce, you must also consider how this data will affect your backup window. There are usually only a certain number of hours each night during which a backup can be performed. You need to determine whether it is realistic to expect this additional data to be backed up within the backup windows using your existing backup solution.

Questions for pre-development

Naturally, the specifics of the development process and the pre-development meetings will vary considerably, depending upon the type of application that is being developed, the size of the company, and the corporate culture. Even so, I have prepared a set of questions that you can ask your developers during various stages of the development process. Not all of these questions will be appropriate for every situation, but they should be enough to help you think of questions that are appropriate for your own situation.

Development checklist

1. In what language will the application be coded?

2. How large do you anticipate the application being?

3. Will the application reside on a server or on the user's workstations?

4. What operating system does the application require?

5. Does the application require any special drivers or components, such as the .NET Framework or the Microsoft Database Engine?

6. If the .NET Framework is required, what version will be needed?

7. How much memory will be required to run the application?

8. Do you anticipate this application being processor intensive?

9. What is the minimum recommended hardware configuration for users running the application?

10. Does the application require a new file extension to be registered?

11. Do you foresee any compatibility problems with applications already being run by the user base?

12. How many users will be running the new application?

13. Based on the business requirements for which the application is being developed, how many records do you anticipate being added to the database on a daily, weekly, and monthly basis (assuming that the application is database-driven)?

14. How large is the average database transaction going to be?

15. Based on the business requirements for the application, is a nightly backup acceptable or will continuous data protection be required?

16. Will the application require a dedicated server?

17. Will the application be storing data in or extracting information from the Active Directory?

18. Will any special ports need to be open on the user's personal firewalls?

19. What permissions will be required over which directories in order for the users to run the application?

20. Will the application make use of a separate authentication mechanism?

21. What is the time frame for the first beta, and for the final release?

22. How many users will participate in the initial beta test?

23. During the initial testing, will you be monitoring any performance metrics?

24. How will the application be distributed (SMS, manual installation, group-policy-based installation)?

25. Who will be responsible for distributing the application?

26. Once the application is complete, how much time will be allowed for the deployment process?

27. Do you anticipate other departments eventually adopting this application, or the department for which the application is being developed hiring additional users?

28. How will updates to the application be tested and distributed?


Applications developed in-house can affect the network administration staff in a number of ways, even if the development staff is taking responsibility for supporting those applications. As such, it is important that both departments discuss the applications requirements and expected performance long before the first line of code is ever written. It is equally important that the development staff communicate with the network administration staff as the application's development progresses. This will help the network administration staff to stay on top of any changes to the timeline or the application's requirements.

About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at www.brienposey.com.

On one hand, this is not as serious as a casual user purchasing and installing a third-party application without your consent. For one thing, developers should have a pretty good idea of what the company's computers are and are not capable of. Likewise, if there are problems with the application, then the job of supporting the application and correcting those problems will usually fall to the development staff. On the other hand, it is still critically important that the network administration staff and the development staff work together. Even if the development staff is going to take full responsibility for supporting applications they create, those applications will have some impact on the network.
This was last published in November 2006

Dig Deeper on Network application performance