Rational case that explains in nontechnical terms

an article added by: Ben Smeider at 11272007


In: Categories » Computers and technology » Servers » Rational case that explains in nontechnical terms

Once you have learned what you need to know, the next step is to begin to put together a calm and rational case that explains in nontechnical terms what the vulnerabilities, risks, and costs are. The case must include a discussion of the risks of inaction.

Find Allies

Ask around your organization. Look for friends and colleagues who share your concerns. Maybe you’ll find someone who has tried to convince management of something in the past. At the very least, though, it is best if you can find people in other organizations who agree with you and who can help build the case. If you are a Windows system administrator, speak to the Unix system administrators and see if they agree with you. Contact database administrators, as well as network and storage administrators. If the problem that you have identified is a real one, it surely affects some of these other people. Maybe you can also identify some end users who share your concerns and invite them to join the fight. If your organization is large enough to have multiple facilities, contact peers in other facilities and see if you can find allies there. If you can demonstrate to management that your concerns are shared in different parts of the organization, your case will be much stronger. On the other hand, if you can’t find allies in a medium- to large-sized organization, that may be an indication that your efforts will not succeed and that you should probably reconsider your efforts.

One problem that can arise when you bring in additional people is that different people have different perceptions of a problem, as well as different priorities. To be successful, you must take input from every member of the team and make sure that their concerns are addressed in the final presentation. It may become necessary to compromise and change the level of priority that certain issues receive. But if you aren’t willing to compromise, you run the risk of having some of your allies drop from the effort or, worse, form a competitive group. If that happens, both movements will likely fail.

Develop a Set of Recommendations Once your list of vulnerabilities and ratings is complete, it’s time to develop a list of recommendations. If you have made a solid and sober case, and you can follow that with some equally well-thought-out recommendations, you will maximize the likelihood that you’ll get the resources you are looking for. Choose no more than three or four of the most serious vulnerability scenarios— the ones with the highest likelihoods and impacts. Develop complete plans to address each of them, with alternatives at different cost levels. Choose one that you like best, and recommend it the most strongly, but make sure that all of the alternatives are palatable. The recommendations should include a pure business discussion of costs versus risks, along with those old business school chestnuts return on investment and time to payback. What are the objectives? Why are we discussing this? What is the potential benefit to the business? Be as specific as possible. Discuss the impact on current ongoing operations of implementing your solution; will there be downtime? How much? What will it all cost? When estimating costs, be sure that your numbers are realistic. If someone challenges you on acquisition or implementation costs, be sure that you can defend your numbers. Cite sources for your information. Discuss the hidden benefits of your proposal. For example, will having better recovery plans result in a reduction in the enterprise’s business interruption insurance premiums? (You may not be able to accurately determine this, but it’s something to include as a potential hidden benefit. For example, a completed and tested disaster recovery plan can reduce these very expensive premiums by 20 percent or more.) If the plan includes purchasing additional computer equipment or real estate for a disaster recovery site, what additional benefits can these resources provide the organization? Will you be able to offload backups from primary systems? Will you be able to house additional personnel? Is there a chance the property value will rise? Remember that financial arguments are most likely to get attention from upper management.

Be sure you also consider the short- and long-term business impacts of extended outages to the organization’s reputation. Will there be front-page articles on our experiences? How will those articles affect future business? And then there are the intangibles, like loss of market share and investor confidence. Your outage could put you in violation of all sorts of industry regulations, including some of the ones we discussed before. Your outage could even tarnish the reputation of your entire industry. It could also alienate customers, either present or future.

legal notice

Our website is not responsible for the information contained by this article. Web-articles is a free articles resource.
Suggestion: If you need fresh, daily updated content for your website, feel free to use our service. Click here for more information.

Useful tools and features

Link to this article from your page    Send this article to you or to a friend
If you like this article (tutorial), please link to it from your web page using the information above.

related articles

1. Definitions for downtime vary from gentle to tough
Defining Downtime Definitions for downtime vary from gentle to tough, and from simple to complex. Easy definitions are often given in terms of failed components, such as the server itself, disks, the network, the operating system, or key applications. Stricter definitions may include slow server or network performance, the inability to restore backups, or simple data inaccessibility. We prefer a very strict definition for downtime: If a user cannot get her job done on time, the system is down. A computer syste...

2. File and Print Server Failures
Network Failures Networks are naturally susceptible to failures because they contain many components and are affected by the configuration of every component. Where, exactly, is your network? In the switch? The drop cables? Bounded by all of the network interface cards in your systems? Any of those physical components can break, resulting in network outages or, more maddeningly, intermittent network failures. Networks are also affected by configuration problems. Incorrect routing information, duplicate host...

3. Web and Application Server Failures
Web and Application Server Failures The bugs that can strike a database can also affect a web server. Of course, many web servers are part of client/server applications that query back-end database servers to service client requests. So, anything affecting the database server will have an adverse effect on the web server as well. However, there are many other places within the web server environment where things might go awry. There are many new places for bugs to crop up, including in the Common Gateway Interfa...

4. Your system fails because the operating system panics
Renewability Let’s say your system fails because the operating system panics. It reboots, restarts applications such as web servers and databases, and continues on as before the failure. What’s the probability of another failure due to an operating system panic? In all likelihood, it’s exactly the same as it was before the reboot. There are many cases, however, in which repairing a system changes the MTBF characteristics of the system, increasing the probability of another failure in the near-te...

5. Direct and Indirect Costs of Downtime
The Costs of Downtime The only way to convince the people who control the purse strings that there is value in protecting uptime is to approach the problem from a dollars-andcents perspective. In this section, we provide some ammunition that should help make the case to even the most stubborn manager. Direct Costs of Downtime The most obvious cost of downtime is probably not the most expensive one: lost user productivity. The actual cost of that downtime is dependent upon what work your user...

6. COST OF DOWNTIME IS NOT A CONSTANT
Further complicating matters is the fact that the cost of downtime is not a constant. We will assume it to be constant for the purposes of our calculations (it makes them much, much simpler), but in reality, the cost of downtime increases as the duration of an outage increases. Consider again the effects of downtime on an e-commerce site. If the site suffers a brief outage (a few seconds), the cost will be minimal, perhaps even negligible. An outage of a minute or less probably will not affect business too badly: All...

7. The Politics of Availability
To persuade others of the value of your ideas, it is necessary to delve into the dark, shadowy world of organizational politics. Fundamentally, this means that you achieve your goals by helping (or if you aren’t particularly scrupulous, appearing to help) others around you achieve their goals, so that they then help you achieve yours. Start Inside Probably the best way to convince others of the value of your ideas is to first convince them that your ideas will help them achieve their own goals. To do that, yo...

8. 20 Key High Availability Design Principles 1
#20: Don’t Be Cheap One of the basic rules of life in the 21st century is that quality costs money. Whether you are buying ice cream (“Do I want the Ben & Jerry’s at $4.00 per pint, or the store brand with the little ice crystals in it for 79 cents a gallon?”), cars (Rolls-Royce or Saturn), or barbecue grills, the higher the quality, the more it costs. The decision to implement availability is a business decision. It comes down to dollars and cents. If you look at the business decis...