1: Defining Your Strategy
This chapter focuses on the tasks of articulating a problem or opportunity, specifying a solution, and justifying its value, with specific emphasis on business requirements.
(EN: I don't think the author means "business requirements" as the detailed document used in project planning, but more in the rationale that explains the interests of the business in determining and justify the objectives that necessitate a project to be undertaken.)
Define a Business Solution to the Problem
(EN: The author seems to skip the step of defining the problem itself. From an IT manager's perspective, problems are often presented by the business, and the expectation is that you'll jump right into solution-mode without pausing to consider if the problem is valid at all, or if it may have been wrongly diagnosed, or if IT can even provide an effective solution That's sometimes politically necessary, but otherwise, it's best to spend a bit of time considering the "problem" to determine if it's real, and worth solving.)
Defining a solution entails examining all the options available and select the best one, then determining the objectives for addressing it. He briefly mentions the idea of copying an existing solution as a starting point, but with the need to consider it carefully to determine if it's a good fit and, especially when copying a competitor, looking for a way to improve upon it to gain competitive advantage. He also obliquely mentions the allure of new technology, and implies that technology should not drive business strategy.
Also, especially in the case of opportunities, there may be multiple courses of action that are mutually exclusive, either due to their nature or the availability of resources.
Generally, this results in a high-level concept such as "increase our turnaround on inbound orders," which in turn needs to be expressed in more detail (by replacing our outdated logistics system), and then in even deeper detail.
Justify the Value of the On-line Operation
The decision to pursue an operation is generally based on cost-benefit analysis, in which the value produced (or saved) by the project is used to justify its cost.
(EN: there's a lengthy explanation of how to calculate costs, a superficial stab at managerial cost accounting - I'll skip it, as there are better sources - and will stick to things that seem to be unique to software projects.)
The author discusses the "cost" of availability - in terms of the impact that the organization suffers from the unavailability of a system (lost revenue, the cost of doing business by other means) to arrive at a cost, per minute, of unavailability. This includes not only the immediate loss in business (customers who can't buy because the site is down), but an estimate of the costs of correcting errors in partial orders, the cost of labor to restore system functionality, the cost of employees who sit idle, the potential "permanent" loss of regular customers to competitors, penalties for missing service guarantees, loss in shareholder confidence, damage to brand image, the cost of precipitating lawsuits, etc.
(EN: Some of the logic here seems specious to me, and the calculations seem geared toward exaggerating the costs. It's also worth noting that outage costs are often based on when they occur, how long they last, and their frequency. I don't mean to suggest that the cost of outages should be ignored, but that there are probably more reasonable and rational ways to calculate them )
Also, small outages have a large compound effect. A LAN that experiences 1 second of down-time every thirty seconds due to a malfunctioning switch causes a loss of about 9 hours of employee productivity per year, and if the LAN is used by 5,000 employees at an average salary of $30/hour, the net cost is $1.35 million per year.
(EN: This is where it gets fishy: the loss is only incurred if an employee's productivity depends on constant data traffic rather than activities that require periodic data communication. It also assumes that the funds could be recovered in cash if the employees had the two seconds per minute back, or that all those spared seconds could be gathered together so that head-count could be reduced. Most of this is likely to be entirely false, and replacing the switch would save a negligible amount of real money)
Another note on downtime: beware of percentages. A system that has 99% uptime will be offline for three and a half days a year. If an online retailer's site is offline for that long, especially during holiday shopping season, it could destroy their financial performance that year and undermine consumer confidence for the future.