BRIAN FAWCETT (BF): Most organizations perform a business impact analysis, or BIA, before creating a full business continuity, or BC plan, but they typically treat it like a one-off affair. And that's an issue.
I'm your host, Brian Fawcett, and this is IT Availability Now, the show that tells stories of business resilience from the people who keep the digital world available.
On this episode of IT Availability Now, we have Jon Murry, Principal Consultant at Sungard AS, here to explain why businesses should regularly conduct a BIA to ensure they are as resilient as possible.
Jon, welcome to the show.
JON MURRY (JM): Thanks for having me, Brian!
(BF): For those who might not be that familiar with this topic, can you explain the main functions of a BIA?
(JM): Sure. A BIA is the study of the business that focuses on the vital business process and all things upon which those processes depend. We do this by identifying the impacts to the business if there were disruptions, such as a physical disaster, like a tornado or hurricane, or it could be a disruption to technology. It could even be a pandemic, as we’ve all seen. Anything that could disrupt the business.
So, the first thing we do is we identify the core business processes. So when doing that I’m looking at different industries. Sometimes I look at hospitals and what are their core processes? They have to do surgery or they have the ER but they also have processes like their payment cycle and how they get revenue and communicate with insurance companies.
Or we might look at a retail organization that's doing payment processing to credit cards at their retail stores or maybe they're doing it online. These are all key processes that we want to look at so that we can understand what they're doing. And then we look at the dependencies, all the things that they need to keep those core processes going. We want to break those dependencies down by the resource type.
The first resource type I look at is the applications and data. So, if we think about the hospital, they've got applications that are doing things like imaging, so that the surgeons have a good picture of what they're doing when they get in there and do their work. We're looking at applications in that retail example, that are connecting them to VISA, Mastercard or different banks so that they can do payment processing. The applications in data are critical. It’s the first type of resource we look at.
We're also looking at people in the staff, all those skills that they’ve got. Those are critical resources. We're looking at the facilities. So that could be an office building, or it could be a data center, or maybe it's the warehouse where you store your product. And then the last resource type that we look at is third parties. These are your vendors, these are your business partners, supply chain, all of that, we want to look at when we do a BIA. If any of those resources stop functioning, they can't perform their function for any reason, we want to understand what the impact to the organization would be.
We have to measure those impacts, quantify them. What's the cost of downtime? And the cost can be measured in dollars, of course, but it's also measured in less tangible impacts, such as customer service. How many customers touch your website in any given time? If they were down, you would have that impact on customer service. And then also the impact to reputation, your brand, maybe even your market share. So, you could lose investors, market share, you could lose customers. So besides just looking at costs, we need to look at all those things.
And it's important to know when you're doing a BIA that you want to gather this in data. You want it to be data driven because if I can get that data of how many dollars, how many customers are impacted, then I can sort it, I can filter it, I can look at it in lots of different ways through different lenses.
For instance, I talked about business processes and the idea of understanding the cost of downtime in business processes, but we also want to be able to look at it across different applications. The application may support multiple processes and if it does I want to be able to aggregate that data, that potential loss data.
Same thing if it's a facility. If I’ve got an organization that has multiple offices, maybe regional offices, I might want to pick one office that's particularly vulnerable. Let's say if I'm In Miami I’m worried about a hurricane and I want to be able to aggregate the potential loss data to just that facility and say if I lose that facility, what is my potential risk, my potential vulnerability? Because ultimately what we're trying to do is prioritize the business processes and all of those resource dependencies so that we can develop strategies to help you protect the organization and give leadership that prioritization so that they can make good sound business decisions on what to protect. How quickly to be able to recover? What strategies can they employ to do that? How much should they spend?
(BF): So, this is a robust study of a business. Why can't organizations get away with performing a BIA just once?
(JM): It's just the ever changing, increasingly fluid nature of business and technology today. How does it change your strategy if you move a key system to the cloud, for instance? What are the potential ramifications if you decide, let's say, to outsource your call center? So sometimes when you make these decisions, you’re making it to save money, but you’re potentially increasing the risk if you're putting all your eggs in one basket. Or if you're losing control by outsourcing something, you may create more risk even if you’ve reduced some of your costs.
So the pandemic is kind of a good example. So many organizations have sent their people to work from home and this has worked pretty well for some companies. Some of them have decided to make this a permanent solution. And that's good from a lot of perspectives including it keeps the people separated from the single office building. So, in that way, it gives you more options and reduces risk in a disaster. But it may bring in new risks that you hadn’t thought about like what about your internet providers and your VPN? If you can lose your VPN service, now you have lost your entire workforce because they can't get into their key systems. So that kind of a finding in a BIA might lead the organization to make the VPN stronger, more robust, more resilient, or even redundant, right, so that they don’t have the loss of connectivity for their staff.
So, performing a BIA regularly or refreshing the BIA is truly the catalyst for making those strategy decisions and changing and updating your business continuity plans.
(BF): What factors should businesses be considering when conducting a BIA?
(JM): Well dependency mapping for one. The BIAs identify your organization's key products and services but understanding what those key products and services depend upon is paramount. The dependencies can be all kinds of things like staffing. It can be different skill sets of your people. It can be different vendors or suppliers, but often the most vulnerable dependencies that we're really looking at are those applications and the data that they house. So, we want to map those applications to the key products and services to understand when those applications are supporting multiple products and services and then we can look at it across the entire business.
Regular BIAs track the evolution of those application dependencies so you can understand the priorities and keep your BC plans up to date. Just think about when you move those applications to support another process, or you leverage it for different things. I should also mention, the same goes for adding and subtracting technologies from your environment.
(BF): Why is that?
(JM): Well, everything changes when you roll out new applications or if you remove obsolete ones. Those new applications have tentacles that reach into all your processes. And if you just think about whenever you bring something new in how it changes what the end-user is doing. It could be your staff is doing something manually or using a phone and now you’ve implemented a new software, a new application, like let's say a web portal, that allows your customers to interact directly online. So instead of doing things on paper, instead of doing things on the phone, everything’s in that portal. So that data is there. You want to make sure you're backing it up and protecting it. Really the whole process has changed when you do something like that.
So, we've got to study in our BIA, how essential is the new application to your business now? How does it fit into your recovery strategy? How is the data backed up? How is it protected? And what's the impact of the downtime? If you don't keep up with the changes, then you won’t know how disruptive an impact to your key business might be.
I had a client a few years ago, an auto lender, and they offer auto loans to used car dealerships and new dealerships all over the globe. So those applications that calculated the lending rate and populated the screens at those dealerships with different lending options were really key, and they were happening all the time, 24/7, across the globe. So, when that application went down, they couldn't see their lending options, and the dealership would go to the next thing, the next option there. And we could calculate by the minute how many loans this organization would potentially lose, how many dollars they could lose. So, it was very powerful in helping leadership understand what they needed to do to make that application redundant and they wanted to invest the money to do so.
Like adding new technologies, you can't overlook the effect that consolidating your systems, environments and facilities could have. Moving systems to the cloud, maybe one cloud provider, certainly has advantages in terms of cost and efficiencies. However, having your key systems more distributed can reduce the risk of losing everything at the same time or to the same disaster. When I think about having all my systems connected in the same place to the same servers, then I worry about issues like ransomware. Performing BIAs will help you stay mindful of how adding or reducing resources can affect your overall resilience.
(BF): That all makes sense. And you talked a lot about identifying key applications. But you also mentioned that businesses must know how the downtime of each affects your business and how does a BIA calculate that?
(JM): The cost of a disaster is typically tied to duration. One of the first things I want to do when I conduct a BIA is work with the organization's leadership to determine the time durations that we're going to measure. I want to set up common time windows so that we can study our impacts and put them into those time buckets if you will. So the business and the type of business should really dictate what those durations could be. So if you're doing an online retail business, every minute can be key. You have a lot of customers that are touching your application by the minute. If you're doing something that's not quite as time sensitive, you might want to measure by the hour, or oftentimes by the day.
So you set up these windows for each organization and then you can standardize those windows, which helps you normalize the data across all the different business processes. You'll see that different business processes have different critical times. So when we have these nice buckets of time or windows of time that we put their impact data into, then we can really measure and normalize across those windows.
Once you have all the impacts measured and in consistent time windows, we can turn those time windows into application tiering. So we decided that these systems need to be up and running within one minute, we really can’t tolerate very much downtime. That limits what strategies we can employ. It really means you're going to have to have some kind of replicated redundant cloud strategy, something like that. Whereas if you have critical systems that have been determined to be important within, let's say 72 hours, we can use a very different, much less expensive process for recovering that, such as you're recovering from tape backup to a cold data center site or something like that. It's really those time windows, how you figure out your application tiering, which helps you set the strategy. And as your organization evolves, so will your mission critical applications, so you need to regularly re-evaluate the strategies and use a BIA to do that. This will help you identify the impacts based on time, determine your recovery objectives, build strategic recommendations for increased business resilience and availability and then deploy those practices.
(BF): So Jon, who determines what applications are most critical to your business?
(JM): That's a great question and it's another reason why the BIA is so valuable and why I enjoy doing them. The BIA is a business study, so it gives the business side of the organization the opportunity to weigh in on what IT is doing to support them. So, it's a benefit for IT and a benefit for the business. IT often doesn’t have, isn't given any criteria for when something needs to become resilient or available or redundant. This is the business’s chance to tell them. Everything from the tiering of applications to contractual guarantees from critical vendors.
For example, if the business side needs a certain application to remain available, like my auto lending application that I gave an example earlier, then the BIA will justify a cloud strategy with real time backup and replication as a tier one application should be. And thinking about it, about the same level of criticality can be weighed and should be weighed and measured against vendors. This ensures that there's either a guarantee of availability from the vendor or maybe a secondary vendor to service backup.
(BF): One last question. Let's go into that topic of vendors a bit more. As we saw with the recent Facebook outages, companies can run into trouble if they rely too heavily on a particular partner and that partner experiences a disruption. How does a BIA help in that regard?
(JM): Well you need to know that your third party partners will be there for you when you need them, but you also need to know how their downtime might affect your business. Do you know how your key vendors will support you if they have a disaster that affects them?
You know, I have a client in Memphis, Tennessee, and they have a key supplier who resides on the other side of the Mississippi River. We did a BIA. We looked at their vulnerability and ultimately, my client decided that they needed to get a secondary vendor, a backup vendor, that's on this side of the Mississippi just in case a physical disaster made crossing the river impossible.
But also, just like your key applications and systems, your vendors can change. They change their methods and their applications. So it's important that examining their resiliency is not just a one and done exercise. Just like self-examination, it has to be repeated regularly to keep up with their changes. A BIA evaluates third party risk to identify any single points of failure that might put your organization at risk.
(BF): That’s great advice, Jon. To reduce the impact and duration of a costly disruption, organizations should consistently update their BC plans as their businesses change. And this begins with performing a BIA regularly to address those changes. Doing so will allow you to uncover evolving application interdependencies, calculate the cost of downtime, identify third party risk and more ensuring your company's resilience is where it needs to be, no matter what.
Jon, appreciate you coming on podcast today.
(JM): You bet! I had a great time.
(BF): Jon Murry is Principal Consultant at Sungard AS.
You can find the show notes for this episode at SungardAS.com/ITAvailabilityNow.
Please subscribe to the show on your podcast platform of choice to get new episodes as soon as they’re available.
IT Availability Now is a production of Sungard Availability Services.
I’m your host, Brian Fawcett, and until next time, stay available.