BCROI: Measuring Returns on Investmenthosteddocs.ittoolbox.com/bct-measuring-roi.pdf · 2013-11-13 · 4 businessContinuityToday.com BCROI: Measuring Returns on Your Business Investment

BCROI: Measuring Returns on Your Business InvestmentDon’t fall into the trap of viewing your investment in Business Continuity as an insurance policy. The ROI is very real and very rewarding.

eBook 8Published November 2009 by Vision Solutions

BCROI: Measuring Returns on Your Business Investment Don’t fall into the trap of viewing your investment in Business Continuity as an insurance policy. The ROI is very real and very rewarding.

BCROI: Measuring Returns on Your Business Investment

Table of ConTenTsChapter 8: BCROI: Measuring Returns on Your Business Investment

Foreword ...............................................................................................4

The Insurance Policy .............................................................................5

The Value of (Lost) Data ........................................................................9For Some Companies, BC Is the Law .......................................................10

Moving Beyond the Insurance Perspective ..........................................10Planned Downtime Avoidance .................................................................11Offloading Tape Backups ........................................................................14Improving Performance ..........................................................................15 Enhancing Business Intelligence .............................................................16Going Back in Time ...............................................................................17Real-World Testing .................................................................................18

Choose the Solution that Maximizes BCROI ........................................19Buy or Rent? ........................................................................................20

Data Safety and Security ....................................................................21 Data Center Location .........................................................................21 Disaster Invocation.............................................................................21 Non-Disaster BC Benefits Impact .........................................................21

Netting It Out ......................................................................................22

sign up To beCome a member As an eBook member, you will be the first to be notified when Chapter 9, Making the Green Connection:Ensuring Sustainability and Continuity appears in print!

Receive information from IBM and Vision Solutions, Inc.

Making the Green Connection:Ensuring Sustainability and Continuity

businessContinuityToday.com4


foreword

A few years back, a new term entered the CFO’s lexicon: CFROI. It is short for Cash Flow Return on Investment, a financial valuation measure that was originally developed by HOLT Value Associates. As the name implies, rather than look at accounting profits or other performance measures, CFROI considers cash flows, discounting them to take into account the time value of money, including inflation. The total of these discounted cash flows is then divided by the market value of the capital that is employed by the corporation or investment. In basic terms, CFROI is a different—and many believe more effective and realistic—tool for comparing the value of different corporations and projects and determining where one’s money is best applied to gain maximum returns.

It’s time for a similar change in perspective when considering investments in IT-related business continuity (BC) projects.

In the past, IT-related BC investments were considered to be insurance policies. The thinking was this: “Disasters rarely happen, and we might never suffer one, but we still have to spend a lot of money to be prepared just in case we do.” From this viewpoint, an investment in BC was often considered to be, at best, a necessary evil.

And that’s at best. Using the insurance policy mindset, in tough economic times, when every prospective investment is scrutinized even more carefully than usual, organizations may be tempted to forgo that BC “insurance policy” altogether, simply in order to save a little money.

That’s a mistake because BC is more than just an insurance policy. It delivers a number of significant, tangible benefits that accrue to the organization even if it never experiences a disaster, benefits that can be realistically and accurately quantified.

To avoid mistakenly forgoing a very worthwhile BC solution, it’s time to make a more comprehensive evaluation of the true total return on BC investments. This evaluation must take into account the value that is overlooked in the traditional “insurance” theory of BC.

ChapTer 8BCROI: Measuring Returns on Your Business Investment

Business Continuity is more than just an insurance policy. It delivers a number of significant, tangible benefits that accrue to the organization even if it never experiences a disaster, benefits that can be realistically and accurately quantified.



With a tip of the hat to CFOs, let’s call this new value calculation BCROI, Business Continuity Return on Investment.

The insuranCe poliCyWhile the worth of the insurance element of BC is not the only—nor even the greatest—value you will receive from an investment in BC, it is definitely one of the benefits. But, because it is the most tenuous and difficult to quantify of the values that BC delivers, let’s get it out of the way first.

The insurance benefit of a BC investment is earned only if a disaster occurs. In light of that, how do you value the benefit? After all, it’s something that you may never receive. In fact, you fervently hope that you that won’t receive it.

The logical starting point for resolving that question is to define “disaster.” The word likely makes you think of a hurricane, earthquake, tsunami, fire, or similar event. Those certainly fall into the disaster category but, in the context of this discussion, “disaster” means something more.

For our purposes, what matters is what trigger event will cause the “insurance policy” component of your BC solution to pay out its benefit. In this context, a disaster is any unplanned event that—in the absence of geographically separated, full replicas of all hardware, software, and data—causes the destruction of the online copies of much or all of an organization’s production data and/or causes business operations to stop for an unacceptable period.

What is an unacceptable period? It all depends. (You knew we were going to say that, didn’t you?) Unfortunately, that’s the best answer we can give because it depends upon your specific business situation.

At a large online stock brokerage, the metaphoric meter registering the ongoing cost of downtime due to a disaster may run at the rate of millions of dollars per hour. In that case, the term “acceptable downtime duration” will likely be denoted in minutes and not have more than two digits. For example, imagine a company of this description didn’t currently have a backup power generator to support its data center. Because of the huge hourly cost of downtime, that firm could classify the risk of a half-hour power outage as a disaster that the company must insure against. Clearly, the cost of a generator to ensure continued operations during a fairly short power outage is justified.






On the other hand, a small manufacturer that receives most of its orders in the mail—snail mail, not email (yes, it does still exist)—and that has little or no computer-controlled manufacturing equipment might be able to continue to operate almost indefinitely without access to its information systems. Administrative productivity may decline, but selling, manufacturing, and shipping operations will suffer only slightly. This type of firm may consider a few days of downtime due to rare events to be acceptable. Only an event involving many days of downtime might be considered a disaster.

Now that we have a definition of “disaster,” the next question is, what value will you receive from an investment in reducing or, preferably, avoiding the downtime that can result from one?

A natural reaction would be to throw up one’s hands and exclaim, “That’s ridiculous. You can’t assign a value to that. A disaster may create horrendous effects that you can’t possibly put a price on. What’s more, even pushing the unthinkable aside, you can’t reliably predict whether you’ll suffer a disaster in any particular year much less how long it will shut down your operations, can you?”

The correct answer is “yes and no.”

Let’s deal with the touchy subject first. Yes, at its very worst, a disaster can result in a loss of life. Putting a value on that will always be, to say the least, an exceedingly thorny matter. Fortunately, you can avoid the issue entirely when considering IT-related BC investments because the objective of the exercise is not to prevent disasters or their direct effects on people or particular physical objects; that’s not possible for the types of solutions under consideration. The objective is to minimize operational downtime due to the data and application unavailability that a disaster can cause.

As to the unpredictability of disasters, that’s true. However, if a company is in business long enough, you can pretty much guarantee that it will, at some point, suffer a disaster (as we’ve defined the term) of some magnitude—hopefully, only a minor one.

Despite not being able to reliably predict whether you will suffer disaster in any particular year, there is a theory in the realm of statistics that can help you to assign a meaningful value to the insurance policy aspect of BC investments: expected value theory. Without getting into the theory in too much detail, to assign a value to an outcome that may or may not occur, multiply the value of that outcome if it does occur times the probability that it will occur.

Expected Value = V x P

Where: V = potential value received P = probability of receiving the value

What value will you receive from an investment in reducing or, preferably, avoiding the downtime that can result from one?



To calculate the expected value of an investment that will reduce downtime in the event of a disaster, you need estimates for three variables: the probability of a disaster occurring during the period under consideration, the average amount of downtime that will be avoided during each disaster if the investment is made, and the hourly cost of downtime.

The most difficult to estimate of these three factors is the probability of a disaster occurring. To determine how likely it is that your organization will suffer a disaster, first look at history. Using the broader definition of disaster provided above, how frequently have disasters struck your organization in the past? After answering that question, if you can find them, analyze statistical averages for the frequency of disasters in your geographic area to adjust your internally generated disaster-frequency estimate. (Geography is important because the frequency of some types of disasters varies by location. For example, hurricanes, tornadoes, earthquakes, or wildfires are relatively common in some regions but virtually unheard of in others.)

Make an educated guess as to the probability of experiencing a disaster in any given year. Base that educated guess on the best information you can find, but don’t fall into the “paralysis by analysis” trap. A rough estimate of this probability is likely the best you will be able to derive, and, fortunately, it is usually more than good enough.

We’ll label this probability “P.” Note that if, using the above loose definition of disaster, you expect to experience more than one disaster per year, then P will be greater than one. Otherwise, it will be greater than zero, but less than or equal to one.

The average length of disaster-related downtime is much easier to estimate. If you’ve experienced any disasters in the past and haven’t changed your disaster recovery strategy and tactics, then the past is a good predictor of the future. However, if the business has grown since the last disaster recovery effort, the recovery time estimate will have to be adjusted to account for the larger volume of data, and possibly the additional applications, that must be recovered.

Even if you’ve never suffered a disaster or, rather, particularly if you’ve never suffered a disaster and therefore have no in-house experience in disaster recovery, it is prudent to perform at least annual, and preferably quarterly, tests of your disaster recovery processes. Those tests will clearly demonstrate how long it will take you to recover after a real disaster using your existing recovery processes.

We’ll label the amount of downtime per disaster that can be avoided by an investment in BC as “T.” It’s measured in hours.

Even if you’ve never suffered a disaster or, rather, particularly if you’ve never suffered a disaster and therefore have no in-house experience in disaster recovery, it is prudent to perform at least annual, and preferably quarterly, tests of your disaster recovery processes.



Much has been written elsewhere about the cost of downtime. In addition, some BC vendors offer Web-based tools to help you calculate that expense. Suffice it to say that the costs include lost sales revenues, lost employee productivity, lost employee morale, lost customer loyalty, data recovery labor costs, and penalties for not fulfilling various obligations, including service-level agreements (SLAs), in addition to other factors specific to your industry and organization.

Suffice it also to say that if you haven’t yet performed the downtime cost calculation, you’ll probably be surprised by the result. Intuition tends to vastly underestimate the total costs. To give intuition a little help, consider the following average hourly downtime costs for different types of businesses. Gartner, Inc. provided the values in 2002.

Inflation and industry consolidation has, undoubtedly, driven some of these costs higher today.

We’ll label the average hourly downtime cost as “C.”

With these estimates in hand, the annual expected value (“EV”) delivered by the “insurance” component of a BC investment can be calculated this way:

Given the number and magnitude of the unknowns that are factored into the equation, the veracity of the result is, to say the least, questionable. Nonetheless, that’s not the major issue that normally arises after organizations perform this computation. It’s certainly an issue, but it’s not biggest hurdle that organizations must overcome when trying to justify an investment in an advanced disaster recovery (DR) solution. The problem is that P,

$ USD (est.)Brokerage Operations $6,450,000

Credit Card Authorizations $2,600,000

E-Commerce $ 240,000

Package Shipping Services $ 150,250

Home Shopping Channels $ 113,750

Catalog Sales Center $ 90,000

Airline Reservation Center $ 89,500

Cellular Service Station $ 41,000

ATM Service Fees $ 14,500

EV= P x T x C



the probability of a disaster, is generally so low as to provide an ROI that is below the organization’s investement “hurdle” rate. Or it may even suggest that the investment will generate a negative ROI.

If the analysis stops there, the organization may forgo a potentially very profitable investment because too much of the value was omitted from the analysis.

The Value of (losT) daTaIt is important at this point to emphasize that, even just considering the insurance aspect, the above equation may greatly underestimate the value of investing in BC.

One factor overlooked in the expected value formula provided above is something that is referred to as “orphan data.” When you depend solely on tape-based backups to protect your data, you invariably put some data at risk. The reason for this is that backup tapes are generally created no more frequently than once a day, typically at night. Insertions, updates, and deletions applied to your databases between tape saves will not be reflected on any backup tape. The data that has not yet been adopted by any backup tape is orphan data.

If a disaster destroys your primary data center, including any database journals, orphan data may be lost forever. The question that must be answered in order to make the expected value equation more fully reflect the BC insurance benefit is, what is the value of that lost data?

Again, the best that is possible is an educated guess. How much data will be lost depends on when the disaster occurs. If the data center was destroyed shortly after the backup tapes were created and those tapes were shipped offsite immediately, then little data will be forfeited.

Consider, on the other hand, an organization that holds backup tapes onsite for a day so the tapes can be used to rapidly recover data corrupted by lesser problems that are much more frequent than disasters. This hypothetical organization ships the backup tapes offsite only when they are one generation old. If a disaster strikes its data center just before a new set of backup tapes is about to be created, as much as two days of data will be lost.

Not only is the volume of lost data unpredictable, but the value of each lost data item is difficult to calculate and varies for different types of data. For example, the data from an online banking transaction is very valuable as it directly represents cash and there is no paper trail for the transaction. In contrast, a manufacturer that receives paper-based orders in its remote sales offices and keys them into a central database sometime later will be less concerned about a loss of the electronic copies of the data as they can be recreated from the paper records.

If a disaster destroys your primary data center, including any database journals, orphan data may be lost forever. The question that must be answered is, what is the value of that lost data?



For Some Companies, BC Is the Law

There is one more factor to consider before moving away from the consideration of the insurance value of BC. In many industries, such as the financial sector, data protection isn’t just good business policy; it’s the law. In many companies, the regulatory environment is such that protecting all customer and corporate data, and ensuring that it is always readily available, is a minimum cost of doing business.

For these companies, beause of the risk of orphan data and because of the length of recovery times, traditional tape-based backups are not good enough. To comply with the law and stay in business, they have no choice but to invest in a disk-based BC solution, even though the probability of needing to use it to continue operations after a disaster is very low.

At the risk of sounding overly dramatic, it needs to be said that, if yours is one of these companies, you should add another factor, the Value of Staying in Business (VSB), to the above expected value calculation so that it looks like the following:

moVing beyond The insuranCe perspeCTiVeGood. The hard part is out of the way. Now we can move on to some of the more predictable, quatifiable, and tangible benefits that BC investments can deliver.

But first, a little background is in order. The question that often arises is, how can a disaster recovery solution deliver value if a disaster never happens? The answer is that today’s BC technolgies offer much more than disaster recovery.

Consider the gold standard in BC solutions. Under this scenario, an organization maintains two or more fully redundant systems in different locations using real-time replication. With enough distance between the replicas, a disaster that strikes one data center will almost certainly have no physical impact on the other(s), no matter how severe the disaster may be. To make this solution work, replication processes within high availability (HA) software replicate all changes to the organization’s applications and data—including system data—from whichever system is acting as the production server to the remote location(s) in real-time.

EV = (P x C x T) + VSB



The high availability software usually also provides functionality to detect the unavailability of the primary system and then initiate an automated failover to the backup system, or at least to automate and conrol a manually initiated switchover. Either way, because of their relative ease of execution, a failover or switchover may also be initiated to keep the business running smoothly after an unexpected event that is classified as something less than a disaster. Better yet, a properly implemented and maintained high avilability solution can be used to eliminate almost all “normal” planned downtime, including downtime that is otherwise required for normal server, application, and data maintenance.

Because switching over to a remote system typically takes longer than a local switchover, the organization may also include some level of local redundancy. This may be a completely redundant environment, or it may be redundant servers that share switchable disk storage.

Overall, the biggest contributor to the BCROI that this type of solution provides arises from the fact that it can be used to reduce or eliminate downtime, not just due to unplanned events such as disasters, but also due to unavoidable, frequently scheduled maintenance.

Planned Downtime Avoidance

Fortunately, most organizations are struck by disasters only, as they say, once in a blue moon. Unfortunately, the same can’t be said for scheduled maintenance. It happens much more frequently, often daily.

Because of the high frequency of planned downtime, the value that a BC solution delivers by allowing you to avoid downtime due to maintenance activities typically provides a far greater portion of the return on your investment than the disaster insurance benefit. The ratio of planned to unplanned downtime varies, depending on the reliability of the platform you use, but for the vast majority of firms, less than five percent of downtime is unplanned.






Thus, when you consider only the disaster insurance aspect of a BC investment, you are looking at only the benefits delivered in typically less than five percent of the time that a BC solution can provide benefit.

In fact, even that overstates the case. That five percent represents all unplanned downtime, including events such as power failures, software crashes, and operator errors. Most of these incidents would not trigger a disaster recovery operation, so avoiding their affects would generally not be considered as part the disaster insurance benefit of a BC solution.

Why is there so much planned downtime relative to unplanned downtime and relative to disasters, in particular? There are a number of reasons.

Rarely, if ever, do more than two years pass between new releases of the operating systems running your business servers. In addition, patches may be available monthly or—in the case of a critical security patch—maybe more frequently than that.

You might be able to skip a release or two, but eventually features that are too good to pass up or applications that won’t run on your current operating system version will force you to upgrade your operating system.

Depending on the upgrade process and whether it is successful the first time, without a BC solution in place, downtime due to an upgrade, or even just a patch, can last anywhere from a few minutes to a few hours.

When implementing a new version of an application, it is often only that application that must be shut down during the upgrade process, but, depending on the application, that downtime can be very costly.

In addition to operating system and application upgrades, from time to time you also have to upgrade your hardware. Even if you are willing to live with old hardware technologies, the growing demands of the business will eventually force you to buy a machine with more processing power. The downtime incurred to upgrade hardware can be even longer and more costly than for applications and operating systems.

And, on a fairly regular basis, you have to reorganize your databases to reclaim lost space and improve performance.

The redundancy provided by a BC solution offers a way to avoid the downtime that would otherwise be required to perform maintenance. When you must, for example, reorganize your databases or upgrade hardware or software, simply switch users to the replica system. By doing so, the only operational downtime that the company will suffer is the time required to effect the switch.

The redundancy provided by a BC solution offers a way to avoid the downtime that would otherwise be required to perform maintenance.



Calculating the value provided by this benefit of a BC solution is much easier than performing the insurance value calculation above. Because planned maintenance is common, history is much more likely to be an accurate predictor of the future than it is for disasters. To get a sense of how much planned downtime you will incur in the absence of a BC solution, calculate an average of the annual planned downtime you have experienced over the past few years. Use that as your estimate for future years.

Because there is some brief downtime when switching between replica systems, you’ll need to look at not only the total amount of downtime you incurred in past years, but also the average number of downtime events each year. Multiply this number by the downtime required to effect a switchover. Subtract the result from the total average annual downtime hours for maitenance activities performed in the past. The result provides a good forecast of the number of hours of downtime you can avoid each year by implementing a BC solution.

To assign a dollar value to this benefit, multiply your forecast of avoidable downtime hours by the average cost of downtime.

The average hourly downtime cost that you should use in this calculation is usually considerably less than the number that is appropriate when calculating the insurance value of a BC solution. The reason for this is that the timing of disasters is random. The probability of them occurring exactly when they will cause the most damage is equal to the probability of them occuring exactly when they will cause the least damage. The appropriate hourly downtime cost to use when calculating the value of disaster downtime avoidance is, thus, the weighted average of hourly downtime costs throughout the day and over the course of the year.

Planned downtime, on the other hand, can be scheduled for when it will have the least impact on business operations. Thus, avoiding an hour of planned downtime is, on average, less valuable than avoiding an hour of unplanned downtime. Nonetheless, the frequency of planned downtime relative to unplanned downtime typically makes planned downtime avoidance the much more valuable benefit over the course of a year.

Once you have estimates of the number of planned downtime hours (H) that can be avoided annually with a BC solution and the value (V) of each of those downtime hours, the equation for calculating the annual value of avoiding planned downtime is simply H x V. An expected value calculation is not necessary because maintenance is a sure thing.

You might have noticed that we didn’t specifically mention in the above discussion one of the most common types of maintenance: tape-based backups, which typically occur daily. The reason is that this special case will be discussed in the following section.



Offloading Tape Backups

Even after organizations have implemented a fully redundant, disk-based BC solution as described above, they typically still create tape-based backups as a last line of defense. That’s prudent. Geographically dispersed, simultaneous data destruction is almost impossible. Almost, but not quite. The extra measure of safety is worth the small cost of tape-based backups.

For organizations that haven’t yet implemented a BC solution, tape-based backups often aren’t just the last line of defense against data destruction. They are the only defense.

In the past, organizations had no choice but to quiesce business applications while creating tape-based backups of critical data. This wasn’t a serious issue when business systems ran only during “business hours.” Then, backup tapes could be created at night when most business applications were shut down anyway.

Globalization, the Web, and competitive pressures that force organizations to more fully leverage the value of fixed assets have made a mockery of the old term “business hours.” For many organizations today, every hour is a business hour. For them, systems are, ideally, never shut down.

“Save while active” technologies have, theoretically, made it possible to create tape-based backups without stopping business applications. Where these technologies are available, there is no longer a technical requirement to shut down applications while creating backup tapes. However, in practical terms, continuing business operations while creating tape-based backups may still not be an option.

Tape backup jobs attempt to pull all data off of disks and copy it to tape as quickly as possible. Thus, while the backup jobs are running, the system’s processors may be tied up and the disk I/O channels may be jammed. The result may be that application performance slows to an unacceptable crawl.

A BC solution that maintains a real-time replica of the production databases can enable you to avoid these problems. Because the secondary server contains all of the data on the production system and it is current right up to the instant, backup tapes can be created using the secondary system, thereby removing the backup-processing load from the production server and eliminating the need to quiesce applications.



This solution offers another advantage over backup jobs that are run on the production server using a save-while-active technology. Most of the replicators in high availability software provide the ability to temporarily stop the processes that apply replicated updates to the backup system. This allows you to create a stable recovery point from which to take your backups. This helps to protect the integrity of the data on your tapes.

In this case, the HA replication processes on the backup server continue to buffer any updates that arrive from the production system. These buffered updates will be applied to the backup database when the apply processes are restarted after the tape backup job is complete.

The alternative, creating backup tapes while updates continue to be applied, might lead to a situation where incomplete transactions are backed up. This may make it impossible to correctly recover your databases from the backup tapes. Unlike the types of maintenance described in the previous section, creating tape-based backups in a redundant BC environment does not require a switchover to perform the maintenance task. Simply change the location where you run your backup jobs.

How much will these benefits contribute to the return on your business continuity investment? Of the two potential benefits—avoiding backup downtime or avoiding the application performance degradation resulting from using save-while-active—it is easiest to forecast the value of the downtime avoidance benefit. To estimate this value, record how much downtime is currently incurred due to the running of tape backup jobs now. Then multiply the number of downtime hours by the cost of downtime at that hour of the day.

If, rather than incurring downtime, you use a save-while-active technology to keep applications running during tape save jobs, but productivity is hampered because the backup jobs hamper application performance, estimate the percentage of productivity that is lost. Multiplying this percentage by the average downtime costs at that hour of the day will yield an adequate estimate of the value of the lost productivity.

Improving Performance

You might have guessed another benefit of moving backup processing to the secondary system: It moves the processing load off the production machine, thereby freeing up valuable processor resources.






But backup jobs aren’t the only processing tasks that you can move to a replica server. To avoid the need to deal with “data collisions”—data items that are updated simultaneously in different locations—applications that update data are generally all kept on the production server. However, most organizations have a number of applications, such as batch reporting, that are query-only. With real-time replication in place, these query-only applications can all be run on the replica system, without any danger of generating data collisions.

This delivers a couple of benefits. For one, the decreased load on the production system will improve the performance of the applications that are still running there. To estimate the value of this benefit, forecast how much employee productivity will improve as a result of the improved application response times. As a rough approximation of how much this will add to the return on your BC investment, multiply the estimated percentage productivity improvement by the total salaries, wages, and burden rate for the affected employees.

When evaluating the productivity improvement, don’t look at the performance hit that your production server is currently suffering due to batch reporting at only one point in the month. Month-ends, quarter-ends, and, particularly, year-ends often place a heavy reporting burden on systems. Looking only at the mid-month affect of report processing on business application performance will underestimate the productivity improvements. Similarly, measuring the performance degradation that occurs during financial period-ends will overestimate the value.

Improved application response times aren’t the only benefit you’ll receive. Moving some of the processing load off the production server will defer the need to upgrade that server to accommodate business growth. The way to value this benefit is to consider the cost of the upgrade and the length of time it can be deferred. Then use the company’s internal rate of return to calculate how much the company can earn on an investment of that size for that length of time.

Enhancing Business Intelligence

It is the nature of business analysis that you don’t know what you don’t know. As a result, valuable business intelligence can often best be generated by random walks through massive databases to search for unexpected patterns. However, when all reports and analysis must be run against production data, those random walks might be deemed to be too large a detriment to operational efficiency.



Often, analysts can run the reports they need, but because of the impact they have on production application performance, IT may insist that the jobs be run at night, when the operational systems are either shut down or not particularly busy. Unless the analysts camp out in front of their computers, this limits the number of report runs they can execute. If a report turns up something interesting that requires further investigation, the analyst may have to wait until the following night to explore it further.

Reducing the frequency of query, reporting, and analysis jobs in this way slows the flow of business intelligence, sometimes to a standstill. And the slower the flow of business intelligence, the longer it will be before business analysts have their “eureka” moment and the longer it will be before they can initiate actions that will generate value from that insight.

Again, by moving query, reporting, and analysis jobs to a replica system, thereby removing their processing load from the production system, you can also remove the throttles that IT has placed on business analysts. In doing so, you free analysts to be more productive and to increase the creation of valuable business intelligence.

Going Back in Time

Some high availability products include a function known as Continuous Data Protection (CDP). CDP can make it possible to recover individual data items to any point in time, not just to the time when a backup tape was created or to the moment of a failure due to a disaster.

This is important because most data integrity problems do not result from catastrophic failure. Isolated corruptions of small portions of a company’s data, possibly just a singe data item, are much more frequent. There are many examples of this type of data integrity concern. An operator accidentally deletes a file. A disk drive fails in a way that corrupts a small portion of the data on it, without bringing down the applications using the data. A virus makes it past the company’s defenses and deletes or corrupts some data. And so on.

CDP solves these types of problems in a way that tape-based backups and traditional high availability solutions can’t.

With tape-based backups, you can recover data to only a few discrete recovery points—namely, when the tapes were created, likely once a night. Consider a data item that is updated regularly throughout the day. If it is corrupted at, say, 2:00 in the afternoon, your only recovery option in a tape-based environment is to restore the data to the state it was at when the backup tape was created during the previous night. Then you must manually try to recreate the updates that were applied from the time the backup tape was created until the time the data corruption occurred.



Traditional high availability solutions don’t help in this situation either. High availability products maintain exact replicas of the production data. If an update is applied to the production database, it is immediately replicated to the backup database—even if that update corrupted the production database. Thus, a high availability product will faithfully reproduce many data corruptions on the backup system, not through some fault of the high availability software, but because replication is exactly what it is supposed to do.

CDP solves this problem by keeping copies of every data update. It also provides automated tools that allow the software to use these records of data updates to restore data to a particular point in time.

(Note: There are two types of CDP. Real-CDP provides the capabilities described above. Near-CDP batches updates and, therefore, can restore data only to particular recovery points, not to its state at any point. However, these recovery points are typically far more frequent than is the case with tape-based backups.)

Because the types of problems that CDP solves tend to be relatively frequent, if you have good records of operator activity, you may be able to generate a reasonably good forecast of the value of this benefit. With CDP, an operator can often recover individual data items in minutes. Compare this to how long it typically takes to recover data in these sorts of circumstances in your current environment. Multiply the difference in recovery times by your hourly labor costs times the number of data recovery tasks that are normally performed in a year.

Real-World Testing

If application testing is to reliably detect problems with software before it is released to users, those tests must accurately reflect real-world conditions. To do so, the data that the tests work with must closely mirror actual production data. Some BC solutions may provide a feature that can help you do this by allowing you to easily create production data snapshots on the fly.

This feature is usually included in the software to provide a capability similar to CDP. It allows you to create a variety of recovery points of your choosing.






However, that doesn’t mean that this is the only use you can make of snapshot functionality.

Many companies use production snapshots to create real-world test databases to improve the effectiveness of their application testing efforts. When the testing is complete, the snapshots can be deleted without ever putting the production data at risk from the testing activities.

You likely won’t be able to put a meaningful, tangible value on improved testing or testing with accurate yet disposable datasets, but it is something to keep in mind when trying to determine if a BC solution will deliver an adequate ROI.

Choose The soluTion ThaT maximizes bCroiThe BC solution universe includes a range of options. The one that will deliver the highest BCROI for your organization depends on your situation.

For example, the gold standard of BC solutions was described above as including fully redundant, geographically separated systems that are kept synchronized in real time. This solution provides the ultimate protection against both planned and unplanned downtime.

Not all organizations can justify such a comprehensive solution because it can be quite costly due to the need to acquire, maintain, and administer two adequately sized servers, both of which must be capable of running production operations. A less costly solution may make more sense for some organizations, even if the solution doesn’t provide BC capabilities that are as robust as the gold standard.

For example, if you use an operating system that allows for the creation of logical partitions, you can create one production partition and one backup partition on the same physical system. You can then use high availability software to maintain a replica of your production applications and data in the backup partition.

This solution eliminates the cost of a second system, but it still gives you the means to continue operations while performing many types of maintenance tasks. Obviously, because this solution is limited to a single location, it won’t protect you against downtime due to a disaster. But, depending on the nature of your business, tape-based recovery might be adequate for this purpose despite its long recovery times and the potential to lose orphan data.

As an alternative to the single-system high availability approach, or possibly as an adjunct to it, you might choose to use a remote “data vaulting” technology.



Data vaulting captures updates applied to a production system and copies them to a second system. The data vault stores only the raw updates, rather than trying to maintain a hot-standby backup server. Because the updates are stored in a simple file structure, the data vault doesn’t have to use the same operating system as the production system and it doesn’t require much processing capacity. And, therefore, it can run on a low-cost, commodity server.

Data vaulting virtually eliminates the orphan data problem inherent in tape-based backup strategies because updates can be transmitted offsite electronically in near real time.

When using a data vault, in the event of a disaster, data is typically first recovered from tape. The server is then brought fully back up to date using data from the vault. Consequently, data vaulting doesn’t shorten the electronic phase of a disaster recovery effort. However, when you consider the effort required to manually recover the orphan data that would be lost in the absence of a data vault, total recovery times are generally significantly lower when a data vault is available.

Buy or Rent?

Finally, you could consider moving your BC out into the “cloud.” Just about any aspect of data processing—from server capacity to communications bandwidth and data storage—can be obtained from specialized vendors. Because it is still a relatively new option, this kind of “outsourcing” of IT is discussed and branded under many names, including Software as a Service (SaaS), Hardware as a Service (HaaS), and cloud computing. But the core advantages and disadvantages are the same.

Consider again your goal. Yes, instead of investing in capital equipment, perhaps your money is better applied to contracting a service provider. For example, have your existing server(s) replicate to someone else’s server farm. When seeking to achieve optimum CFROI from money invested in BC, you may consider running the numbers on such third-party, service-based options rather than investing in capital equipment and your own facilities.

But, when you do, be sure to include stringent analysis of the potential costs associated with outsourcing. Beyond the basics of reliability and simple capability to perform, there are potentially less obvious issues to consider:



» Data Safety and Security What contractual obligations does the vendor have with regard to compensation to you if they mishandle data? What if their servers are breached and your data is lost, corrupted, or potentially sold off on the black market? This scenario must be evaluated with the service provider’s capabilities and financial strength in mind, compared to the scale of your business being entrusted to them.

» Data Center Location Be sure you know exactly where your data is being held. The Web makes it possible to host your data anywhere from Indiana to India. Even if you are not a 24x7 business, ensuring that your service providers can support you fully at any time of any day, for disasters and for daily operations, is vital.

» Disaster Invocation What costs will be involved if you must shift your operations to run on the servers at your high-availability service vendor’s facilities? What fees and services will be involved to get your business back online if your primary data center is impacted by a true disaster?

» Non-Disaster BC Benefits Impact If you are relying upon a third-party provider for your high availability and disaster recovery, do you in fact have immediate and complete access to the backup data and servers in order to take advantage of the BCROI benefits we have just discussed? Do you have total control and access for CDP data recovery and/or for performing and testing tape backups from the secondary system? Are the capacities for which you are contracting expandable so that building complete, fully functional test environments can be done without incurring excessive charges for services beyond the base contract?

In summary then, outsourcing one or more aspects of your BC environment is possible. Just be sure to capture in your BCROI calculations all of the potential costs and risks as well as the proposed benefits. Because realistically, when you are investing in BC, you are putting your business on the line. It is worth every effort, every meeting, and every hour of crunching numbers to ensure that your investment is not only financially sound, but also operationally solid.

When you are investing in BC, you are putting your business on the line. It is worth every effort, every meeting, and every hour of crunching numbers to ensure that your investment is not only financially sound, but also operationally solid.



neTTing iT ouTThere are far too many options for BC investments—and far too many combinations and permutations of options that might be employed in a single enterprise—to be covered in this one discussion. In the end, the bottom line is that clear and careful assessment of the full BCROI of any investment is imperative. To maximize your BCROI, you must first carefully analyze your BC needs and wants in the context of the nature of your business operations and the regulatory environment under which you operate. Then, attempt to estimate the value of fulfilling those needs and wants. Finally, find the BC products, or combination of products, that will deliver the highest BCROI by providing the greatest value relative to their cost.




Documents

BCROI: Measuring Returns on Investmenthosteddocs.ittoolbox.com/bct-measuring-roi.pdf · 2013-11-13 · 4 businessContinuityToday.com BCROI: Measuring Returns on Your Business Investment