Information Availability: How to Utilize and Reference Architecture

In the preponderance of the organizations we support, a key impediment to effective Disaster Recovery is the fact that it is an afterthought in the system lifecycle – rather than a component of the overall solution architecture.

This results in tactical Disaster Recovery solutions, implemented after the fact, seen as “additional costs” to the system itself. Reference architectures, that include availability and recoverability as part of the overall solution set, enable more proactive investment and a more effective solution.

It seems that the health of US corporations improves (ever so slightly) each quarter. IT spending has come along for the ride. After many budgets shrunk from 2008 to 2010, Gartner reports that spending on Information Technology grew 6.9% in 2011, but they are projecting a smaller percentage increase (3.7%) in 2012. Corporate leadership is looking for more intelligent spending and leverage of new innovations. They are looking for returns from past investments in Information Lifecycle Management (ILM), deduplication, virtualization and cloud computing.

Those innovative technologies have each come with some promise of helping availability and disaster recovery. They have collectively smoothed out the “spectrum of availability” – from incidents, disruptions, outages and disasters. This result of this has been the virtual elimination of end-user and customer tolerance for outages. Regardless of whether the application is a consumer website, a hosted logistics system or software as a service CRM application the person accessing it will not understand. The problem is that availability comes at a cost to the company.

As recently as 5 years ago there was still a divide between the availability of production applications and disaster recovery of those same applications. The production operations teams talked about 99.999% availability and Minimum Operating Levels (MOL) while the Disaster Recovery team would measure recovery times and points. In most cases there were two separate disciplines, organizations, architectures and responsibilities. Another manifestation of that divide was terminology confusion – fault tolerance, availability, disaster recovery, and then of course the ultimate goal: resilience.

That disconnect and confusion results in inefficiencies that create overhead and increased cost to the organization. The terminology confusion makes it very difficult to communicate to business management and executives about functional requirements, technology investments and risk management. Business leadership has been reticent to allocate sufficient budget to availability and recovery because IT organizations have poorly represented it – trying to build a business case with fear, uncertainty and doubt instead of objectivity. It really is a vicious cycle.

A tool that will help to bridge the gap just described is reference architecture. In its simplest form it provides a common vocabulary with which to discuss implementations. A reference architecture – sometimes called enterprise architecture –is a communications vehicle that helps simplify and drive decision-making in the organization. Let’s take a closer look at a reference architecture that would be applicable to the availability and recovery discussion.

To reemphasize – the goal of the reference architecture is to bridge the gap between availability and disaster recovery while also providing a set of common terminology to decrease confusion. The example architecture below describes the different tiers of criticality, but it describes them in terms of both availability and recovery. It uses the Impact to Critical Business Functions as the common terminology to assign the applications to tiers. While most readers will be familiar with the Recovery Point Objective (RPO) and Recovery Time Objective (RTO), some may not know about the Minimum Operating Level (MOL). The MOL is the lowest operating level that must be met to support business processes.

The reference architecture should be developed by the IT organization. It is best when an operations function is a key member of the development. However, the operations group will have to work with storage, server, and disaster recovery teams to develop the initial cut of their reference architecture. There should be multiple discussions about the appropriate tiers, characteristics and parameters in the reference architecture. Once it has been thoroughly vetted (not finished) it can be used to collaborate with the business.

IT now has a tool to foster discussion (workshops and interviews) with the business. By collaborating with the business and possibly educating the business on terminology such as MOL, RTO and RPO an organization will improve the chances that they are not confused by these drivers or the terminology. By explaining the scope and business criticality associated with each tier, the business leaders will understand the availability and recovery requirements. They will make more logical decisions about potential investments required in the future.

Depending on the tier in which the applications are placed it will determine the type of availability and recovery strategies that are deployed. The important point is that these strategies will be better synchronized because the different groups implementing them have a common medium – they will speak the same language.

These strategies for availability and disaster recovery will cut across facilities, networks, servers and storage. The reference architecture will serve as the foundation for creating other architectures like computing, network and storage architecture. The figure below shows the characteristics across each of those elements.

Once the reference architecture is completed you can use it for many purposes. The recovery architecture can help improve executive decisionmaking by providing that common terminology. That in turn can provide the foundation for initiating strategic changes. Strategies can be helpful in building availability and recovery into future environments. This can be accomplished by taking some basic steps:

1. Obtaining the capacity forecast for storage, servers, and the network.
2. Applying those capacity forecasts to the appropriate applications in each of the tiers.
3. That forecast will then help the management team determine future expenditures.

By doing this in a regular cadence (e.g. annually or bi-annually) an organization will increase their return on those business and IT investments. The investments will be more closely aligning them with business needs (i.e. impacts). During challenging financial times for a company – something many companies went through recently – the reference architecture can help identify areas for consolidating and reducing costs. However, the business leaders will also understand the trade-offs when reducing costs. In other words, they will understand the impacts to availability and recovery. This is enabled by that common language.

An IT organization can use its baseline and current state for computing, storage and network and the starting point for transformation. Using the reference architecture as the requirements definition it can serve as the integration point for future design – architectures and roadmaps. The roadmaps will be thoughtout and have traceability to decision-making.

There are many business transformations that are made smoother by using these reference architecture concepts. It is an important gear, whose cogs help turn other gears. Those gears include high availability, disaster recovery, data center design, and new innovations. There reference architectural can be extremely powerful in helping shape the future design of corporations in a cost efficient manner.