Mainframes pose a significant challenge for business continuity planning. In spite of the inherent computing power and resilience core to mainframe availability, the systems can go down, and it is hard to create a recovery environment.
Modern mainframes, like the IBM zEnterprise EC12, host cloud computing, transactional data processing and big data analytics. But many mainframe shops still treat their business continuity (BC) plans like it's 1964. Mainframe systems are sophisticated and resilient, and in spite of these characteristics -- or perhaps because of them -- many deployments are ill-prepared to address physical disasters and quickly restore operations.
A business continuity plan helps businesses recognize potential disasters, take necessary steps to prepare for them, and outline a scheme to recover and resume operations in a timely manner. BC involves the entire IT infrastructure from mainframe to conventional servers, networks, storage, workload performance and people and processes. Any good business continuity process recognizes the risks, identifies what needs to be protected (such as data or entire systems), determines the current level of protection and how that differs from the needed protection, and takes the steps to mitigate risks or close the protection gap.
The same basic principles of the business continuity planning process apply to mainframe deployments, but the platform creates more challenges than x86 servers or as-a-service cloud apps. Organizations may add a second mainframe, go to the cloud, update legacy applications to x86 platforms or take a different approach.
It's all about the apps
Where will mainframe workloads run if the system is damaged or destroyed? The real "gotcha" is that a mainframe system is so powerful and reliable that there is nowhere else to migrate or restore critical workloads.
A typical business might own hundreds or even thousands of inexpensive x86 servers -- ample opportunity for system redundancy across multiple locations. By comparison, companies rarely deploy more than one mainframe, raising serious concerns for workload migration or recovery.
Mainframes are substantially different than x86 servers. Mainframe applications are based on languages like COBOL with long trails of development. There may not be an easy target restore platform for business continuity -- you can't just spin up an IBM EC12 workload on a Dell PowerEdge R920 Windows server.
Some businesses make a strategic investment in a second mainframe for a secondary facility -- this makes sense if the cost of an additional mainframe is less expensive than lost business or regulatory breaches from an outage. Consider partnering with a third-party mainframe outsourcing provider for a backup system. This requires extensive testing and refinement to ensure that your current workloads and data stores are fully compatible with the provider's equipment, possibly requiring software revisions or updates. A mainframe provider can ensure the level of security and attention without the capital investment in a new mainframe on-site in the DR facility.
Redesigning mainframe workloads to use x86 servers can be difficult, but is a viable option for BC. The application is converted to run on Unix, Linux or Windows and re-constructed for distributed server architectures. Reverse engineering tools help, but expect to do serious software development for refinements, optimizations and bug fixes. Mainframe data stores must also convert into formats suited to the re-architected application and operating system. No matter how you approach it, transitioning an enterprise application off a mainframe system takes time and money.
Boost mainframe BC
Business continuity planning is an increasingly complex endeavor; it's more than just performing and verifying critical backups.
Mainframes typically host critical applications that need more planning than average to improve redundancy and minimize disruptions. Mainframe users, or their business partners and customers, frequently fall under regulatory compliance requirements. Regulations impose obligations in data storage, processing and security, and make demands on ways the business operates or protects itself.
All of these complex considerations can be streamlined through tools designed to organize and automate BC. For example, IBM Tivoli Business Continuity Process Manager centralizes the continuity of computing services, helping IT administrators plan, manage and test preparedness. It also simulates issues to help staff rehearse the business continuity process, and measures the reaction to ensure that continuity performance meets business goals.
Other tools like IBM's Tivoli System Automation (TSA) help businesses develop and implement automated responses to foreseeable problems, allowing for ongoing monitoring and maintenance processes. Tools like TSA support cross-platform applications, data storage and network devices, with workload procedures that include mainframes and other hardware.
While experienced staff can make productive use of these tools, plans and automated responses should be frequently reviewed and revised with a careful consideration of changing business needs. Don't use these tools as an excuse to avoid recruiting, training or contracting with mainframe experts.
Good BC plans cannot be static. All BC plans should be reviewed regularly and thoroughly tested. The process should be updated periodically or as situations change. For example, your long-established data center may be located on a flood plain, but the risk wasn't serious until a fault occurred in a nearby levy. Even with regular attention, the BC plan must be realistic and cannot accommodate every possible situation cost-effectively.
Are business continuity consultants worth what you pay?
Plan for the unplanned with a business continuity strategy