Skip to main content

Panic..Panic..Panic..

Here I am, a day late with my blog, and I haven't a clue what topic I will write about. (Or at least that's what I want you to think.) Yet here I am.

British Petroleum has found out the hard way what the consequences are of not having all of your contingencies accounted for prior to finding out that Murphy is going to hit you where you are weakest. (There's no need to add a link there, since you can throw a stone and hit 20 news websites with articles on the Gulf disaster.) I have also discovered this on a few occasions - most notably this week with my blog (see? I wasn't necessarily fibbing after all) - and I can assure you that losing control of the situation is never fun, especially when the situation wasn't fun to begin with.

My wife says I have "control issues." I counter with the statement that I simply don't like not knowing what to expect.

In ITIL (which is, for those of you who aren't familiar with it, a collection of business processes that have been refined over the years so that businesses can get the most of their investment in IT), Business Continuity is the collection of processes that help you recover from a calamity of any sort. In my own words, there are five primary parts to this.

Develop your recovery plan. When 9/11 occurred, Morgan Stanley very quickly had their operations moved to another facility before the stock market opened that same morning. This quick turnaround time would not have been possible if they hadn't already determined what their recovery plan was.

Document those plans. Another key component is writing down every detail around your recovery plan that is necessary. The litmus test for the effectiveness of the documentation is in the answer to this question: "could someone fresh out of college read these plans and get our business up and running in a relatively short time?"

Be prepared. Morgan Stanley moved to a base of operations on Varrick Street, something that would not have been possible in the short time period if they had not already established this location as a backup center for their operations. I don't know the specifics of the equipment that was already in place before 9/11 but you can easily imagine that they had enough IT assets (including computers, phone lines, etc.) to resume critical business operations with the "turn of a key."

Practice your plans. Disaster Recovery, as it is sometimes called, requires quick execution to prevent (to the greatest degree possible) loss to the business (whether revenue, customers that go to competitors, etc.). This requires that everyone knows their role in such a situation and can simply execute their role with little direction.

Refine your plans. IT is not a static operation. With many moving parts, it is constantly changing as new technologies are incorporated into the business. Periodic review and refinement of your recovery plans is a necessity to ensure that they are in lock step with the current state of the business.

Here's the "big deal" moment. While this all sounds like something that many of you will not have to deal with, a "personal recovery plan" is still an essential component to any successful professional. More specifically, I will make the claim that there are many variables in the business world that make navigation a treacherous activity at times. Corporate politics, the effect of the economy, changing management, etc. can all have an effect on your ability to evolve in spite of the fact that you may be the best at what you do.

Consider the following (with specific names removed for obvious reasons): at a large company last year, the head of a particular division was laid off in spite of the fact that they were quite good at their job and were well respected by everyone reporting to them. The reason, they were told, was that there was someone in their organization that could do their job (although they didn't have benefit of nearly two decades of experience like this individual had) with almost the same level of proficiency but at half the cost. The loss of expertise / experience was more than made up in the salary savings the company experienced. What did this person do wrong? They fulfilled their responsibilities quite well, but at the end of the day it became a financial decision only.

So what is your backup plan? Do you even recognize the need to have one? Once you have this on your radar, you will easily see the benefits of extending this concept to even the finer details of your professional life. Questions such as "How do we continue moving this deal forward if we lose John's sponsorship of our product?" or "How will our [cyclical] business continue to survive if this economic downturn lasts longer than expected?" will be easier to answer with a little forethought and proper planning.

Popular posts from this blog

It's Easier to Fail at DevOps than it is to Succeed

Slippery when wet Since the term DevOps was coined in Belgium back in 2009, it is impossible to avoid the term whether in discussions with colleagues or in professional trade magazines.  And during the years while this movement has gained momentum, many things have been written to describe what elements of a DevOps strategy are required for it to be successful. Yet in spite of this, there is an interesting data point worth noting: not many organizations feel there is a need for DevOps.  In a Gartner report entitled DevOps Adoption Survey Results (published in September 2015),  40%  of respondents said they had no plans to implement DevOps and 31% of respondents said they hadn't implemented it but planned to start in the 12 months after the survey was conducted. That left only 29% who had implemented DevOps in a pilot project or in production systems, which isn't a lot. "Maybe it's because there truly isn't a need for DevOps," you say.  While t...

So What is this IPaaS Stuff, Anyway?

 In my last post , I discussed how no-code/low-code platforms fulfill rapid development of business applications - addressing the needs of the Citizen Developer (a Gartner term  first used around 2009).  I also commented on how this specific objective limits their ability to provide true integration capabilities, which require the flexibility to adapt to the myriad variations of infrastructure.  This is a concern because companies often have acquired legacy systems via M&A activity while simultaneously investing in new technology solutions, resulting in a mishmash of systems with multiple ways of accessing them. In this post, I'd like to examine how the needs of the latter group are met by describing some key capabilities that are "must-haves" for any company looking to execute on a digital transformation strategy.  In order to do this, let's define who the target user base is for such a technology platform. Disclaimer:   I work for MuleSoft (a division...

Application Development Done Right

In a previous article, entitled DevOps as the Ultimate Panacea? , I described how developing code without thinking about the current needs of the end user as well as the future needs once they've become accustomed to using your application ends up not only frustrating them but also can result in customer churn and ultimately lower revenues.  In this article, I'd like to describe something simple that I came across today that shows a definite degree of effort to do quite the opposite. Recently, we had a severe snowstorm, one with blizzard-like conditions, which is unheard of in central New Jersey.  Being responsible adults, my wife and I went to the grocery store to stock up on essentials (read:  chips, chocolate, etc.) in case we get stuck at home. As we were ringing up our order, the cashier mentioned to us that the store has a mobile application.  Since both of us are in technology oriented professions, we were skeptical about the need for a grocery store mob...