With Cloud Computing emerging on the scene as a solution to a number of computing use cases, it will drive modernization of your existing systems. Perhaps it’s just a new interface for driving mobile access to corporate data or consolidating standalone servers into a Cloud for achieving greater utilization from fewer resources. In either case, the number of dependencies between system tiers is increasing shrinking the distance between them.

While we have been trained to believe silo systems are inefficient, they are much easier to develop businesses continuity plans around. In recent discussions with a Director of IT from an insurance company, it was relayed to me that the processes for managing in face of a disaster for his mainframe was well-tested every year for the past ten years. While his process still takes between four and five days to complete, the nature of restoring the mainframe systems are straightforward: turn on disaster recovery site hardware, load applications, load last known data, run missed jobs, etc.

The problem for this individual is that users have progressively stopped using these applications directly in the past five years. Instead, these users are now accessing the mainframe data through a hierarchy of applications that have been built over the years. Moreover, these applications have not been developed as part of a cohesive strategy that incorporates them into the business continuity planning in face of a disaster. So, now, there’s a host of applications that are all feeding each other and there’s no roadmap detailing the connectivity and flows between these applications nor a plan for the order in which they need to be restored in the event of a disaster. We call this dependency creep.

As difficult as dependency creep is as described above, if each of these applications are deployed on silo hardware in a single data center, there’s an opportunity to catalog these applications after the fact. When these applications move into the Cloud and may be distributed across public and private nodes and integrated with other public services, the dependency creep becomes unwieldy and unmanageable. Moreover, without appropriate levels of communications between engineering and operations, these dependencies can become recursive. These recursive dependencies work fine when all services are up and available, but can be extremely problematic to restore if a very specific ordering is not followed.

So, what can you do today to avoid these issues later? First, initiate the development of a DevOps initiative within your enterprise. DevOps fosters communications between engineering and operations so that applications are developed with an understanding of how they will be deployed and operated. When operations and engineering operate in isolation, applications work fine in a pristine test environment, but tend to fall over when deployed in production. Engineers must understand the production environment that their application will be running in and operations must understand how the application works and how it is designed. Building a DevOps group may require individuals to learn new skills to support this effort.

Secondly, develop your IT services catalog. Your service catalog will provide you with the means of identifying dependencies. Unfortunately, the organic nature of IT means that we have built systems with the spaghetti-like interconnections that we typically associate with bad software development. Untangling those dependencies is going to take a concerted effort, but is critical to not only ensuring that you can survive a disaster but that you can respond to less critical outages as they occur without the “fire-drills” that typify many operations environments.

Migrating to the Cloud offers multiple benefits and offers opportunity to solve problems that were previously cost prohibitive. However, any time you open the doors to the data, it seems that the line rapidly forms to consume that data; or as it is commonly known as “build it and they will come!” Furthermore, once the business taps that source, ecosystems will build around it that includes business processes and applications. These dependencies must be cataloged, managed and incorporated into your business continuity planning or it’s very likely your business will be significantly impacted by service outages.