TUG Buzz! for Tuesday August 28, 2018


[article] Common Framework for Resiliency

Garth TuckerWhat do you do when the unexpected happens?

Not in a hundred years did you, or could you, see it coming, and yet here it is. You have no plans for it, have done zero mitigation and you are, as they say, caught with your undergarments in the incorrect configuration.

As a professional, you know not to panic, however, keeping cool under fire from those up and down the ladder is not as simple as the movies make it out to be and our frustration levels creep up as the crisis event goes on and people are demanding action and answers.

I can't say I've never been caught unprepared, and anyone who says they haven't, hasn't been in enough different places, positions or environments to accurately make that statement. Just like seasickness, it happens to everyone at some point if you spend enough time in a boat.

So how do we respond when we don't have a plan?

Simple. You need to have a plan for the unexpected. Huh? What now?

Not a specific plan, such as for an IT outage, but a generic set of instructions on dealing with a range of events. Call it your "Common Framework." Some may say that they use an "All Hazards" approach so they have plans for everything. This is not correct. You cannot plan for everything, and an all hazards approach consists of a 2 phase process. First, an all hazards risk assessment, followed by developing the capacity to deal with many hazards. There is so much more to responding effectively to an event than just those two pieces, they're certainly a good start, but you need to see the bigger picture.

In IT, according to Wikipedia, "A software framework provides a standard way to build and deploy applications. A software framework is a universal, reusable, software environment that provides particular functionality as part of a larger software platform to facilitate development of software applications, products, and solutions."

This translates into our Business Continuity / Disaster Recovery / Emergency Management, let's just call it Resiliency Industry as sets of instructions that apply to different situations, which all share a commonality of response. e.g. Evacuating a building for a flood, fire, explosion, or gas leak is evacuating a building, regardless of the threat which is driving the response. I like to build my programs like I learned to write software many years ago, in modules (subroutines). This way we can pick and choose what we need from the toolbox as a situation develops and we're not tied to specific resources or responses. This gives significant flexibility to the response and is less like turning a battleship and more like cornering a Porsche.

Start by identifying all the commonalities of response in your environment(s) and use this as the base for your "common framework" responses. There's no question that significant customization is required to allow for different environments, facilities, industries, etc., but if you're faced with something you haven't created specific plans for, then you at least have a foundation for a response. Using ICS is probably your best bet for ensuring an efficient, successful response using common forms, language, positions, etc. It identifies all the information that's required to effectively manage an event and puts it into logical, easily communicated forms. If you haven't had exposure to ICS, take the time to learn it and incorporate it into your response .

Things such as contact information for staff, management, stakeholders, etc. should be part of your common framework in a crisis communications protocol/plan which outlines how and whom to contact when an event occurs.

  • Don't accept "I know who to call" as an answer during planning, because sure as a bear does his thing in the woods, that person won't be an available during a crisis and you have no contact information for a critical resource, vendor, or department. My standard reply to that answer is, "That's great that you do, it'll make completing this section much easier."
  • Keep contacts as generic as possible, encourage departments or facilities to have an on-call person who carries "the Batphone" and who is familiar with your common framework.
  • Ensuring generic email addresses, that resolve to several people within a business unit or group, are only used in an actual crisis will avoid email fatigue that may cause critical messaging to be overlooked and improves the odds that a critical resource will respond.

I chose communications as an example because 90% of the events and exercises I've ever been involved in over the years, part of the debrief discussion has always included, "Communications were an issue." However, go back a year later and the debrief discussion in the same environment will likely include that same notation. Nobody likes to build or maintain a crisis communications protocol/plan because it's very onerous to develop and can be a bear to maintain, but it's a key piece of the efficient response to any event and should be given significantly more attention than most give it.

There are a million different scenarios with ten million different responses, but ensuring you do something that's effective when bad things happen is much better than the alternative. Hope that helps!

Garth Tucker, CBCP, CORP
Resilience Professional

Email: garthtuckercbcp@gmail.com
Skype: garthatucker

GarthGarth is a DRI Certified Business Continuity Professional (CBCP), a member of the International Association of Emergency Managers (IAEM), an experienced Disaster Recovery, and Emergency Management planner. His career focus is on the development and management of resiliency programs as well as effective management of crisis events.

The path to his current position began with software development, project and program management, and as an IT technology educator worldwide for IBM in the late 1990s and early 2000s. He transitioned to disaster recovery, business continuity, and crisis management beginning in 2002. Significant formal, and self-education throughout his career has ensured he remains relevant and effective.

Back To Top

iDev Cloud

Sign up now for iDevCloud! You will be able to:

  • Share between multiple developers
  • Get private library and storage
  • Have access to most of the IBM i development tools
  • Have all compilers for IBM i tools available

The Performance is monitored by system managers with adjustments as needed. The system is accessible at anytime from anywhere in the world. Just a computer and an internet connection are needed. Any work done on the system stays on the system until removed by its owner.

Contact Leo Lefebvre at leo@tug.ca to get started.

(*Free startup for TUG members.)

Back To Top

Stay Connected with TUG

The Toronto Users Group is committed to providing you with communications that are timely, relevant, and insightful. Canada's Anti-Spam Legislation (CASL) – which became effective July 1st, 2014 – requires that we receive your permission to continue sending you emails.

You may have already given us your consent. If you haven't done so yet, or if you're not sure, please click on the following link to indicate that you would like to continue receiving electronic communications from TUG.

Should you change your mind, you can unsubscribe at any time, by clicking on "manage your subscription" at the bottom of our messages.

The Toronto Users Group for Power Systems (TUG) is a user group/forum for the exchange of ideas, and specializes in providing affordable education relating to the IBM iSeries, AS/400, System i, and Power Systems platforms. TUG is in its 33rd year of operation.

TUG is the proud recipient of a 2017/ 2018 Maxava iFoundation grant.


Browse our
Articles & Downloads archives

Browse our
TUG Buzz! archives

Browse our
eZine archives

TUG GOLD Members


Do we have your current e-mail address and other contact information?
Email the TUG office to keep us up-to-date.   

Copyright 2018 - Toronto Users Group for Power Systems (Power Systems is a trademark of IBM Corporation.) IBM and the IBM logo are trademarks or registered trademarks of International Business Machines Corporation in the United States and are used under license by IBM Canada Ltd. Linux is a registered trademark of Linus Torvalds. Other logos appear in this message for reference purposes only, and are trademarks or registered trademarks of their respective owners.

(Please note that if you forward this email to any third party, they will be able to view your personal data once they click on the link to Manage Your Subscription, unless you remove that line from the message.)

     eNewsletter design by Eclipse Technologies Inc. www.e-clipse.ca