Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Build mobile apps for iOS, Android and Windows Phone
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Automate decision processes with a no-code business rules engine
When a disaster strikes are you going to be ready? If you can’t answer this question with 100% surety then you have a challenge in front of you. There are many different plans to prepare yourself for a disaster. One that I have seen used both in the public sector in the United States and the private sector is the National Incident Management System (NIMS) and more specifically the Incident Command System (ICS). These have been developed over the last 20 years to help agencies in the United States respond to a disaster. There are similar systems available in almost every country and region around the world.
While both of these programs have been developed to respond to a public disaster – typically a natural disaster – they provide a very good foundation for the complete disaster management cycle.
ICS breaks the process down into 4 discreet components: Mitigation, Preparedness, Response and Recovery. On PSDN, Marv Stone and I will do a webinar / podcast on these components and how OpenEdge 10 meets these needs for your application.
Mitigation deals with identifying requirements (business and safety for example) and minimizing or avoiding those risks altogether. An important part of this process is identifying where you are vulnerable. Once you have identified this you can start to figure out what you “really” need to worry about. This moves right into the planning component of your Disaster Recovery plan.
Planning addresses what options are available, choosing the appropriate option to meet your needs, implementing that option and testing the plan. This is one of the most critical components in the process. It also takes the most time. It is an iterative process and will never be done…
The next component is Response. This is execution of the plan. The first part of this is declaring the disaster. This would seem like a simple thing to do, but it isn’t. I will talk about this in my next blog. This is where your testing with your solution will pay off. Whether it’s OpenEdge Replication, Failover Clusters, or After-Imaging, if you haven’t tested thoroughly then this could turn into a nightmare. A critical part of this process is documentation. Documenting what is being done, who is doing it, and when it was done is critical to the post-mortem (or Recovery) component of your environment. If you don’t document and learn from your mistakes, you will inevitably make them again.
The last component is Recovery. This can be interpreted in several different ways. In the public sector it revolves around returning to life as usual (or as usual as it can possibly be). In the private sector it involves failing back to your production environment and getting the complete business back up in business as usual mode. This is also affected by your planning process. Failing back should be planned and tested in the Planning component of your plan. Documentation is also critical in this component in order to clean up and prevent additional outage time.
Marv and I will chat about these and where OpenEdge 10 plays a part in all of these components of your Disaster Recovery plan. Be sure to listen in!
Until next time, a disaster is only a disaster if you are not ready for it.
Brian Bowman is a Product Manager in the OpenEdge business Unit at Progress, responsible for all facets of Product Deployment and Operations. This includes database, Installation, Platforms and monitoring and management tools.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.