Addressing Availability Early in the SAP Project
Because availability requirements drive the nature of the solution, these requirements need to be understood as soon as possible. Remember, HA and DR requirements limit your choices in regard to certain layers in the SAP Solutions Stack. If you make the mistake of purchasing key solution stack components before your availability needs are made clear by the business, you risk having to toss out substandard pieces of the stack before long. So before you go off and buy servers, database packages, and operating systems, work with the system’s intended end users and other project stakeholders to determine exactly the level of availability needed—what we often refer to as the “nines” of availability.
Determining HA Requirements—The “Nines”
High availability is often measured in terms of percentages that a particular system is “up” or available to be used productively by its end users. Most often, this percentage represents the number of minutes or hours in a year, less the amount of downtime realized by the system due to unforeseen issues—unplanned downtime. In other cases, some SAP customers add up both planned and unplanned downtime when they talk about high availability. Neither is necessarily a better approach than the other. Rather, it’s important that an organization is simply consistent when discussing and measuring their availability goals.
The nines, therefore, are simply percentages of uptime like 99%, or 99.9%, or 99.99% of a year, where a year is defined as follows:
8,760 hours (365 days times 24 hours in a day)
525,600 minutes (8,760 hours times 60 minutes in an hour)
31,536,000 seconds (525,600 times 60 seconds in a minute)
A solution that’s designed for five nines of availability, for example, will be architected to withstand all but the most horrific of disasters, suffering from less than six minutes of unplanned downtime throughout the course of an entire year. Refer to Figure 6.2 for a simple matrix reflecting the most common measurements of availability.
Figure 6.2. Note the “nines” of availability and what each equates to in terms of actual downtime observed by a system.
Throughout this book, it may be helpful to refer back to Figure 6.2 when the topic of four or five nines of availability comes up.
Availability Planning—Documenting Requirements and Key Drivers
At this point in our HA and DR discussions, you need to capture business requirements—the key business drivers that will push the SAP technical support organization, and the solution architect(s) specifically, toward designing a particular SAP solution stack. I recommend that the senior solution architect interview and work directly with the steering committee in this regard. The makeup of the steering committee should reflect stakeholders up and down the end user, IT, and executive management ranks:
The chair and other senior executives/managers, typically responsible for the productivity of large pieces of the end-user community
The key representative from every functional area, such as finance, HR, manufacturing, logistics, and so on
A senior representative of the chief information officer, or the CIO himself
The company-internal project manager
The manager or director responsible for managing the enterprise computing systems upon which the company currently relies
I like to see the senior solution architect take on this responsibility himself, because it’s ultimately too important to the success of the project not to get this right.
| ▸ | For more information on the make-up of the SAP project steering committee, see “The Structure and Role of the Steering Committee,” p. 47 in Chapter 2. |
The solution architect needs to ask questions related to business processes—how critical each one is, typical and worse-case timelines, how disasters are currently addressed regarding the execution of these business processes, and so on. In the end, the SA must architect a system that delivers the highest level of availability needed by a particular subset of the end-user community (the rest of the end-user community gets to benefit from the HA and DR needs of the most critical processes). All of this information will eventually find its way into the project’s knowledge repository, discussed earlier in the book and addressed in more detail toward the end of this chapter.