Collaborative Selling, Part IV
Two Things to Consider Before and After Moving Applications to the Cloud
By Tim Cecconi
At some point in our lives, we've all been warned about the dangers of over-analyzing a situation. But when it comes to rolling out a cloud strategy, the bigger danger lies with making decisions based on partial information or acting prematurely to show business teams
you're moving forward.
Time and time again, I see organizations become preoccupied with implementation and showing results rather than taking the time to 1) thoroughly review the interdependencies of the applications they've earmarked for the cloud and 2) develop, test, and continuously test, a recovery plan for their environments.
Enterprise apps and workloads don't run in isolation. In fact, their value is increased when they work in unison to integrate business processes or share common data—delivering more results than any single app or workload could. On the flip side, when organizations don't take the time to consider interdependencies upfront, the effects can be devastating, rippling across their IT ecosystem and decelerating business operations and transformation initiatives.
Case in point...
Consider if your IT team moves a defined tier-2 billing application to the cloud on the knowledge that it is cloud-enabled. Sounds logical enough. However, if the business has not done the actual testing work to see how all the tier-1 mission-critical applications will work if / when the billing app isn't available, how will you know what the potential loss will be to your enterprise? We see this happen far too often resulting in downtime, loss of revenue, the inability to pay employees and, within the healthcare industry, the loss of ability to provide data for patient care.
Similarly, the lack of a recovery plan, or an untested one, can wreak havoc on a business. With the increasing importance of our data and the seemingly unending threats to its safety due to cyberattacks, it's hard to believe that many organizations still don't have tested recovery plans. But it's true. Organizations think that the public cloud is fully redundant, but is it? Just because your business has data at another site, it doesn't mean you'll be able to 1) recover it or 2) recover it in a timely fashion when you need to.
What to do?
To avoid the pitfalls described above, we recommend a two-step Application and Recovery planning process:
- Have an independent team map the interdependencies between all core applications and between each workload.
- Identify the key IT assets and business functions they depend on.
- Leverage available tools to automatically document application, workload and system dependencies.
- Instill a rigorous automated change management program.
- Implement a "manage and test" process to eliminate surprise in the "go-live" stage.
- Take advantage of management tools that provide a "single pane of glass" view into—and control over—the multiple IT environments you access.
- Manage and update protection at multiple levels to ensure technical security, business continuity and recovery are integrated into your methodology for policy, process and controls.
- Document the recovery process.
- Automate and manage the recovery process, reducing the potential for missed steps or human errors.
- Test at multiple levels throughout the year and at least once per year at the enterprise level.
If you don't have the application or recovery knowledge that's needed, or the resources to divert key staff from business-generating production-focused activities to support functions, engage with a third party
— one that's not dependent on a SaaS or public cloud provider.