The best security policy and most advanced risk management cannot guarantee protection against major failures, such as fire or flooding. Large businesses can afford to duplicate their IT infrastructure in a different geographical location. Most companies cannot afford such a luxury, so they need to have a contingency plan to cope with these types of situations. Suppose you are the manager of the IT department and receive a telephone call in the middle of the night telling you that there was a fire on the floor on which the computer room is located, and there is substantial water damage to the equipment. That is enough to get you awake and reaching for the contingency plan that you (hopefully) always have within arm's length. The plan tells you exactly what has to be done to get the information systems running again, and who needs to be involved. Chances are you will have to set up the system from the ground up. Important factors to keep in mind when doing so include:
■ What type of hardware is needed?
■ What software versions and builds are used for production?
■ Who is going to deliver the replacement hardware?
■ Which backup tapes (which should have been stored offsite) are going to be needed?
■ If the temporary BizTalk environment has to be set up offsite, what needs to be done to hook up this environment with the network at the main location?
Overall, you write the contingency plan for the BizTalk environment as a guidebook to help you to act quickly in case of disaster. For major disasters (also called Force Majeur) such as the entire building burning down, even the average contingency plan can fall short. In these cases, decisions at a tactical level need to be made that might put the execution of the contingency plan out of your hands.
Designing & Planning...
Over the years, I have had many discussions with my clients regarding security and establishing a security policy. Usually, these discussions always went the same way. The business management was under the impression that security meant keeping hackers out of the network, and that a firewall accomplished this. That's all there was to it, as far as they were concerned. When asked what if one of their own employees wanted to do any harm, the default answer was that their personnel would never do this. My default response was always the same: research of misuse and fraud of IT facilities consistently has shown that 75 percent of the time, either current or former employees are to blame. It is an unfortunate fact that most organizations think that threats come only from the outside. Often, healthy business protection is confused with mistrust of personnel.
At this point, I usually ask them when, and for how long, it would be acceptable for a particular business application to be down and unusable. Nine times out of 10, the answer is a resounding "Never!" Next, I inquire as to whether this risk should be eliminated, regardless of the cost. Again, the answer is usually "No, obviously cost has to be taken into account." Going back and forth about what is the acceptable time for a business application to be offline, and what it might cost to minimize the risk of this happening, we end up talking about risk management.
Talking about risk management is talking about IT security policy. Discuss what security measures you need to reduce the risk that the availability of a business application might be disrupted. If management has set these security goals, the IT department can then fill in the technical details.
So, what has this discussion to do with a book about developing BizTalk Server solutions? Everything! Depending on the level of use, BizTalk Server can grow to become the proverbial spider in your information Web. Disruptions or misuse of a BizTalk solution can have severe consequences, such as bringing parts of the company to a standstill or losing both reputation and the goodwill of customers and suppliers. By implementing a security policy and spending money to realize a reliable BizTalk solution, you in fact take out insurance on the continuity of your business processes.
Was this article helpful?