Two Problems, One Solution: What Enterprise Data Backup and Recovery Really Asks of an Organization
Written by David Kramer, Windval Principal Architect
Most enterprise data backup and recovery (DBR) programs do not begin as backup programs. They begin as cost problems, or sprawl problems, or as the aftermath of a security event. Where they begin shapes who sponsors them, how they are funded, and which stakeholders show up to the first meeting. What it does not change is where they have to end up.
For one of our Fortune 200 clients, their data backup and recovery program began the way that many do — as a technical debt conversation inside of infrastructure and engineering. Eight tools. No single control plane. Rising costs, rising complexity, and no clean answer to the question of what happens when something has to be restored under pressure. Windval was engaged to help frame the problem, develop the initiative, and craft the path to implementing a modern data backup and recovery solution. Our tailored approach, rooted in technical depth and cross-organization communication, serves as a blueprint for others to follow when developing an enterprise grade cyber resiliency program.
If your organization is in thinking about launching or in the beginning phases of a cyber resiliency or data backup and recovery initiative, consider lessons learned from our past engagements and the best practice recommendations from our front-line teams to set your program up for success.
-
The instinct in a technical-debt-driven program is to move straight to consolidation. Windval did the opposite: we went back to the business and tested whether the problem was real from the other side of the house.
They cared.
Interviews with data owners, database owners, application owners, and developers surfaced the downstream cost of the sprawl: restores that required manual process, too many panes of glass, and too much coordination at exactly the moment when speed matters most.
That reframed the program. It was no longer a platform refresh. It was a complexity reduction effort with a platform refresh inside it.
-
Once the requirements were on the table, the challenge was not evaluating them. It was reconciling them. Business owners described their needs in terms of customer impact and downtime. Engineering described the same needs in terms of uptime and mean time between failures. Vendors described their capabilities in a third language entirely.
This is where a great many programs quietly stall. Requirements exist. Detail exists. What is missing is the translation layer between a documented business need and an executable technical specification.
Our biggest value is to take whatever loose set of business requirements the client has and find the most efficient way possible to create technical specifications out of that. The engineering manager, the network operations manager, and the application owner are saying completely different things, but they're all talking about the same implementable technical problem.
-
There is a structural reason an independent architecture partner sees the problem differently than an OEM does.
The OEM is like a chef at a restaurant. The customer comes to them and asks a lot of different questions from a lot of different views of their particular needs, and the chef says, well, here's my menu. If you pick anything on here, it's going to answer your question. It's a very one-directional conversation. Windval is the same Michelin-starred chef, but we're having a more open conversation — what do you like, what do you not like, do you have any dietary restrictions, what is your budget, what are your standards? We curate them a five-star meal tailored to their organization and their specific set of circumstances, instead of selecting from a pre-fixe menu.
The destination is often similar. The path to it, and the confidence the organization has in it, is not.
-
Agreeing on the solution is usually the easier part of developing a plan. Agreeing on the order of execution is harder — and more valuable.
In a data backup and recovery program, there are multiple work streams involved, and we need to prioritize and sequence properly to minimize rework and ensure an efficient path to project success.
In the case of recent work, the business's crown jewels were the Oracle databases running financial and customer workloads. By every business measure, they were priority one. The sequencing analysis said otherwise: an equipment end-of-life and technical debt problem elsewhere in the estate had to be addressed first, or the program would incur millions in avoidable cost.
Sequencing is not scheduling. It is the point where technical dependencies, financial exposure, resource availability, and everything else already in flight get resolved into a single defensible path.
-
Multi-year programs outlast the people running them. Over the life of a recent engagement, the client reorganized, leaders changed, and new engineering and operations staff joined mid-stream.
Institutional memory, held externally, is often what keeps a program moving through internal change rather than restarting with every reorganization.
The insight most organizations miss…
If there is one concept to remember when taking on a new cyber resiliency initiative, it is this one:
At the core of cyber resiliency, we’re talking about building a system to recover from security risks and ransomware — building a storage solution for a security problem. When designing that storage solution however, we must be aware of other operational or financial challenges a new architecture can solve for. It is important to bring a holistic, cross-domain view to architecture design for the full value of modern data backup and recovery solutions to be realized.
What to get ahead of…
For organizations planning to deliver a new data backup and recovery solution or are in the beginning phases of a cyber resiliency program:
Validate the initiative drivers from all directions. Whether the initiative originates in infrastructure, security, or the business, it will ultimately have to satisfy all three. Interview all three at the start rather than discovering their requirements at design review.
Establish common language before vendor selection. If the business, engineering, and operations cannot state the objectives in the same words, no vendor evaluation will produce agreement.
Separate the two problems early. Operational recovery and cyber recovery are distinct risk problems that share an architecture. Naming that distinction up front prevents months of circular design debate.
Sequence against cost and rework, not just priority. The most business-critical workload is not automatically the first workload.
Plan for organizational change. Assume the sponsors, managers, and engineers at the end of the program are not the ones who started it, and design your program communications accordingly.