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
Over the last 4 years, we have been working with clients to reduce cost and complexity across their application estates. This involves an in depth look at all components that will affect the overall cost of deployment including:
- Data centre
- People costs
We then map onto the business requirements of the application in order that the optimised solution is fit for purpose. This covers such things as:
- Availability / Resilience
The desired outcome is a happy customer with a minimal technology footprint and compliant licensing position.
This is an ideal outcome where all are happy…
However, the area that raises the most questions is around DR. We generally see the same 4 recurring themes:
- Fit for purpose DR plans that enable multiple Return to Service (RTS) Service Level Agreements (SLA) for multiple applications
- The DR solution was built when the application was first implemented but has never been updated to reflect changes – data growth, integration and new code etc
- As DR is so expensive, only critical apps are covered – question for you, can you define your critical applications?
- Despite best intentions and understanding, no DR is actually in place
To address this area of concern, we have teamed up with leading data centre services provider Alternative Networks to run an event which will help address these and other issues associated with DR. For more details and to register – http://bit.ly/1CrrCBJ
Over the next few weeks this blog will look at 5 key components of your DR plan:
- DR strategy
- Service or Silos
- In house or outsourced – Public or Private Cloud
- Where to start
- Executing the strategy
Everybody has “a strategy” somewhere, either documented or within the heads of the original implementation teams but the question is:
- Is it fit for purpose?
- Does it reflect the fluid nature of your business?
- Has it been communicated across all key stakeholders?
- Has it ever been tested?
- Is it budgeted for in every change to the system?
These are all areas for consideration to ensure that the processes in place are fit for purpose not only to support your organisation as it grows and changes but also in response to your customer’s requirements.
To be effective your strategy should encompass a diverse portfolio of business critical applications required for you to maintain business operations following a disaster.
Business critical applications exist throughout the business and will include:
- Customer facing applications – customers need to continue to buy things
- Supplier management / procurement – you need to maintain delivery capability
- Identity management – your users must be able to sign into identified applications (is active directory your most critical service?)
- Payroll – how long does your staff stay with you if you are not paying them?
- Email – the valuable non junk no social mails
Rarely are any of these applications static. Most will include upgrades, patches, integration with other systems or any number of changes.
So the single most important aspect of any successful strategy is the ability to handle change and the only way to confirm this is for regular recovery testing.
For instance in the database world, there are many ways to copy data; mirroring, block copies, snapshots to name a few. However copying data is not the important issue, instead it is the ability to recover from the copied data that is important. Copying 90% of a database will generally mean that you can’t recover any of it!
Testing will uncover this and other issues resulting in a lost day or two to tweak the strategy and retest. A mild irritation compared to the data loss and downtime experienced as a result of a disaster.
Join us at the Tower to talk through these issues with your peers and industry experts and drop by again next week for part 2 in the series – Service or Silo DRaaS