Nymad and Alternative Networks will be running an event that will help address these and other issues associated with DR. For more details and to register – The Tower
Welcome to part 2 of our blog series focused on securing your enterprise biggest assets, where we delve into an area that our database optimisation engagements consistently uncover as a “grey area” with our clients – DR and whether it exists, is tested and is fit for current purpose.
In this blog we are looking at how, despite best intentions. DR solutions often end up silo’d. If we look at a traditional approach to DR for a smaller business running a single ERP instance, we tend to see something along the lines of………
- a system design and specification that defines infrastructure, storage and network bandwidth
- some planning to define a three year growth strategy (sometimes)
- system build
- integration with (or definition of) an appropriate back up regime
- DR capability assignment
So we’ve got a full “service”, with a fit for purpose DR process (bearing in mind that almost 50% of businesses have never tested their DR processes), that is understood by all stakeholders, hopefully documented and managed to an agreed SLA. But, how long this stays fit for purpose and remains a service, will depend entirely upon how good the process is and more importantly, how important focussing on DR as part of the overall development strategy is.
As a company grows and its user base expands, its systems, more often than not, start to grow and deviate from the original blue print. Classic examples include high availability at the database tier and load balancing at the web tier being built in. Or perhaps a new custom development that requires some code changes. Essentially, data volumes start to grow and grow, to such a point that the DR process effectively breaks. Each component has expanded and developed independently (into ‘silos’) – possibly with their own continuity strategies – so that when invoked, the service can no longer be restored, rather only the silo’d components of it, which are unlikely to work together to deliver the desired result.
Ideally, DR planning needs to be a critical component of any change request, so that DR processes and infrastructure keeps pace with production and a service can be maintained, whilst sustaining the pace of technological investment and business growth. As data volumes increase exponentially, data DR as a stream is a serious consideration to ensure that in the event of an incident, the right levels of data from the required specific period are recovered in time, in the right condition, and for a cost that is commensurate to its value.
- Can we get our data back in time?
- Do we need it all back or can just this year’s data be recovered?
- What is the cost vs value?
Businesses of all sizes and shapes continually shock themselves when they discover their DR plans are out of balance with their applications, and out of sync with their ambitions. That’s why businesses must tune their DR in line with the scale and pace their specific activities demand.
Take a look at your DR plans and ask yourself how much have they changed since they were first put in place. Then look at your applications and ask yourself how much they have changed since you put them in – you may well surprise yourself!
By defining your systems as a series of services, you relate the processes directly to business outcomes. There are however further benefits, for instance, a discrete service can also be outsourced more simply, with clear delineation of responsibilities than the silo’d route.
Join me for the next post where we’ll consider Public or Private, the pros and cons of insource vs outsourcing.