Banking On Middleware Management
Testing For Inter-Platform Connectivity And Recoverability Amounts To A Reality Check.
Most IT managers are caught in the middle between PC networks and a mainframe notsuited to work with a combination of SNA and TCP/IP. What can be done to link theunlinkable and make sure they stay linked in a disaster? A translator, a HP 9000 and lotsof testing.
Farmers & Mechanics National Bank (Frederick, Md.), founded in 1817, is the leadbanking subsidiary of F&M Bancorp, a bank holding company with assets in excess of$1.1 billion.
The bank's 400 PCs are connected to 26 networks and all have access to an IBM 9221mainframe. From our headquarters in Frederick we support connections to 24 Farmers &Mechanics branches, one mobile bank and eight branches of our sister institution, HomeFederal Savings Bank (Hagerstown, Md.).
In our original plan, we wanted the mainframe connected directly with the LAN, but SNAis clumsy in a LAN environment. Because we didn't want to replace our entire network, weadded a HP 9000 D370 server to act as a gateway between the 9221 and our LAN. We installedOpenConnect Systems (Dallas, Texas) OCSII middleware on the D370, which runs as atranslator between the mainframe's SNA and the LAN's TCP/IP.
Clumsy Connection
With this configuration our PC networks and the mainframe cooperate because of the HP9000. In other words, the IBM 9221 hosts the core applications and the HP 9000 providesconnectivity to that mission-critical information. If the D370 fails, the bank's PCscannot access our mainframe data.
Therefore, our disaster recovery plans and federal bank regulators require that we testthe recoverability of our system at least annually. We plan and test for both local andregional disasters. For example, a local disaster could be a fire at our corporateheadquarters that makes mainframe access unavailable, while a regional disaster could be ahurricane or flood.
In either case, our corporate building would be inaccessible and our IT systems wouldhave to be driven from a remote site. In the event of an actual disaster, our goal is tokeep the impact to our customers to a minimum. Ultimately, customers should notice only aminor disruption in service and should be able to continue to conduct their banking.
To ensure the recoverability of our systems, we established a recovery site at IBM'sSterling Forest, New York-based Business Recovery Center. We selected this site becauseit's sufficiently distant from our Frederick headquarters and would be relatively immuneto a regional disaster. The recovery site mirrors our IT systems, including the IBM 9221mainframe and the HP 9000. In case of an emergency, all data can be redirected to SterlingForest.
If IT Falls In A Forest...
In late 1997, Al Takatch, senior microcomputer specialist, went to Sterling Forest toconstruct the bank's recovery procedures. He and IBM technicians worked closely to createour recovery manual. A routine recovery test was scheduled for September 1998.
In September, when the time came to perform the recovery test and simulation, ourdisaster recovery team traveled to Sterling Forest. We simulated a natural disaster andacted as if our IT system was no longer operable. We brought the tapes we would need torebuild the bank's core operating systems and we rebuilt the operating system and softwaresystem, starting as if it were brand new. Then we took the Farmers &Mechanics-specific files and restored them to the HP 9000.
3-To-1 Improvement
The procedure to restore the HP 9000 took approximately one hour and went verysmoothly. That was an improvement over the first time we ran the recovery process lastyear, when it took about three hours. The IBM 9221 mainframe did take a little longer torestore, but its procedure, too, was uncomplicated. When completed, the HP 9000 and theIBM 9221 performed just as well as their counterparts in the home office.
An essential, not-to-be forgotten test, was the connection between Sterling Forest andour branches. We currently lease a line from a third-party vendor and test the viabilityof that leased line connection each time we perform a recovery test. Of all of theprocesses we simulated in September, testing the connectivity presented the greatestchallenge.
Our system complexity level is high because we use several systems to provideconnectivity. Furthermore, new business demands continually present challenges, as theynormally require changes to our networks and systems. It seems that each time we travel toSterling Forest to verify our recovery procedure, there's always something new to test.
Thankfully, during my tenure at Farmers & Mechanics, we've not had an emergencythat would require us to implement a shift of our core processing operations to SterlingForest.
But the flawless recovery test in September validated our confidence that we would beable to swiftly recover from a genuine disaster with minimal or no impact to ourcustomers.
--Scott Williams is the PC Network Manager for Farmers & Mechanics NationalBank.