IT decision: This is a decision as to how something is to be implemented. Everything from the choice of which machine to buy from Dell to what OS, database, programming language, and even which developers to hire. Backup schedules, redundancy, development processes . . . everything.
Business need: Frankly, what does the business need? Or, turned around, what impact does this project have upon the business's bottom line. How much money can this project make? How much might it prevent the business from losing? If this project fails in some fashion, what does this mean for the business? Does the business care or does it shut its doors?
Every rule you've ever been told about "proper" development or administrative procedures comes from the assumption that this project is utterly vital to the business's success. Or, put another way, these rules assume that if the project fails, the business fails. So, that's why you see rules about testing, code reviews, and security procedures that seem onerous in the face of most projects you will ever work on. Frankly, they probably are. These rules were often developed in the context of banks and e-businesses. If a bank has a database breach, it could be liable for billions in liability and trillions in lost customer loyalty. If an e-business, such as eBay, has a database server die and the backup tapes fail, it might go out of business. In those situations, spending a million dollars securing a database is completely in line.
What does this mean for your application? Well, it means that you, the IT person, needs to evaluate the cost of a failure, be it a bug, security breach, or lost backup tape. In a bank or large e-business, the cost is billions of dollars and potential loss of the company. For your database holding the names of donors for a charity, that might be thousands of dollars, but might still also include the potential loss of the company. Your managers need to be aware of this. Once they are apprised of the risk analysis, then they make the decision. And you abide by it.
What?! dragonchild is advocating doing less than the purest process? I advocate the best procedures when I don't know what your situation is. Because of that, I have to assume you're working for a large bank or e-business. If you're not, that might be something useful to mention. Once you have looked at the "purest" procedures, then you are able to determine which steps are not appropriate for you.
An example of the most stringent process is NASA. When NASA has code written, it provides a set of specifications to four different independent vendors. Each vendor provides a separate implementation. NASA evaluates them and chooses the top three to be sent on the mission. In other words, NASA pays for four implementations. And, because of that, NASA's reliability is extremely high. (Before you mention various failures, think about how many satellites are up in orbit and how well Spirit/Voyager are doing.)
Figure out the impact of your project, make a risk analysis, then consciously determine which procedures aren't necessary in your project. Then, don't do them. Every additional procedure is another ongoing cost and another point of failure that needs to be guarded against. Just because you wrote a test suite doesn't mean that the tests themselves are free of bugs. Plus, all the tests need to be updated every time the code changes. Database backups need to be verified. Security procedures need to be pentested. And, everyone involved needs to be trained on them.
Most people are aware of the "9's" method of rating a system. One 9 is 90% reliability. Two 9's are 99%, and so forth until (generally) five 9's (99.999% reliable). The reliability rates how likely a system is to have unscheduled downtime. So, a system with one 9 can be down 36.5 days in a year. Compare that with a system that has three 9's, which can have just over 8 hours of downtime in a year. Five 9's is 315.36 seconds of downtime a year, or just over five minutes. In general, every additional 9 increases the cost tenfold. So, let's say you have a system from Dell for $10,000 that has two 9's out of the box. To go to three 9's, you'll need to spend, roughly, about $100k overall. This would include additional systems (for redundancy), better software, more ancillary equipment (airconditioners, surge-protectors, etc), and more and higher-paid sysadmins. Five 9's would cost about M$10 (compared to the original system).
Risk analysis. Business need. Nothing more.
In reply to IT decisions are driven by business needs by dragonchild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |