Convert Possibilities into Business Value

Tag Archives: Jeremy Carter

I’ve been working on a customer engagement recently that takes advantage of vCloud Automation Center (vCAC), which is designed to centralize and automate key IT activities, freeing the organization to focus on the needs of internal and external customers.

In our deployment of vCAC, I’ve been reminded of a key principal of IT and business transformation: The technology is only part of the process. Often a shift in technology requires a period of assessment and realignment that is as valuable as the technology itself.

When the VMware Professional Services team is brought in for an engagement, the company wants to get the best return on its investment, so the IT team is receptive to our schedule of meetings and stock-taking. But every IT organization will benefit by starting their new technology implementation plan by stepping back to survey the systems in place before integrating a new one.

We put a lot of emphasis on investigating how things are currently done, often starting by asking the teams to draw their processes, for creating a virtual machine, for instance. Frequently we find they have two or three different processes in place, depending on who’s making request. This is especially common in government and higher education, where each department is likely to have it’s own IT team and strategy.

The unfortunate fact is that automation still scares people, thinking they’re going to be out of a job. On the contrary, if you look at any IT organization out there, you’ll see that it’s overwhelmed with tasks, many of which are never getting done. Automation can give them time back to focus on what’s important to their customers.

A new implementation is a perfect opportunity to look at which processes are working the best and align all the teams to them. When a team sees that they’ll be able to provide a better experience and quicker turnaround, their resistance to automation often fades.

And luckily vCAC provides enough flexibility that users don’t have to adopt exactly the same systems across the organization. With a college I worked with recently, we were able to build on what teams are already doing. Next we focused on handoff systems to cut down on the number of emails flying around: one for DNS, another to install the OS, etc.

This process—of assessing current processes, building in automation and consistency, and then refocusing on customer needs—is undeniably valuable. But it does take time. It’s worth putting these reassessments on the calendar every 6 or 12 months; if that doesn’t work, I recommend taking the opportunity presented by the implementation of a new technology to keep moving toward the best your organization can be.

Jeremy Carter is a Senior Consultant with VMware and is focused on the Software Defined Data Center (SDDC). He has special expertise in cloud infrastructure and automation, and BCDR. Over his 14 years in IT he has gained a variety of experience as an architect, DBA, and developer. Prior to joining VMware, Jeremy was a Principal Architect at one of the largest VMware service providers.

When I’m working on a customer engagement, we always strategize to ensure resiliency and failover protection for vCenter Automation Center (vCAC). While these considerations continue to be top priorities, there is another question that seems to be coming up more and more: “What about vCenter?”

vCenter has long been thought of as the constant, the unshakable foundation that supports business differentiators like vCAC. Although we’re happy for that reputation, it’s important for IT organizations to take the appropriate actions to protect all components up and down the stack

This is increasingly necessary as organizations move into an IT-as-a-Service model. As more parts of the business come to rely on the services that IT provides, IT must be sure to deliver on its SLAs—and that means improved resilience for vCenter as well as the applications that sit on top of it.

Our customers have found vCenter Server Heartbeat to be an essential tool to support this effort. Heartbeat allows IT to monitor and protect vCenter from a centralized easy-to-use web interface and protects against application or operator errors, operating system or hardware failure and external. In addition to protecting against the unplanned downtime, it provides improved control during planned downtime, such as during Windows updates, allowing patches without vCenter downtime.

In the past, Heartbeat was most popular with service providers who needed to securely open up vCenter to customers. Now that more IT organizations are becoming service providers themselves, I encourage them to support their internal customers at the same level and make sure vCenter resilience and protection is part of the plan.

Jeremy Carter is a VMware Senior Consultant with special expertise in BCDR and cloud automation. Although he joined VMware just three months ago, he has worked in the IT industry for more than 14 years.

Organizations in every industry are increasingly dependent on technology, making increased resiliency and decreased downtime a critical priority. In fact, Forrester cites resiliency as the number three overall infrastructure priority this year.

A business continuity solution that utilizes the virtual infrastructure, like the one VMware offers, can greatly simplify the process, though IT still needs to understand how all the pieces of their business continuity and disaster recover (BCDR) strategy fit together.

I often run up against the expectation of a one-size-fits-all BCDR solution. Instead it’s helpful to understand the three key facets of IT resilience—data protection, local application availability, and site application availability—and how different tools protect each one, for both planned and unplanned downtime (see the diagram below). If you’d like to learn more on that front, there is a free two-part webcast coming up that I recommend you sign up for here.

As important as it is to find the right tool, you only know a tool is “right” if it meets a set of clearly defined business objectives. That’s why I recommend that organizations start their BCDR planning with a few high-level questions to help them assess their business needs.

1. What is truly critical?

Almost everyone’s initial response is that they want to protect everything, but when you look at the trade-off in complexity, you’ll quickly recognize the need to prioritize.

An important (and sometimes overlooked) step in this decision-making process is to check in with the business users who will be affected. They might surprise you. For instance, I was working with a government organization where IT assumed everything was super critical. When we talked to the business users, it turned out they had all of their information on paper forms that would then be entered into the computer. If the computer went down, they would lose almost no data.

On the other hand, the organization’s 911 center’s data was extremely critical and any downtime or loss of data could have catastrophic consequences. Understanding what could be deprioritized allowed us to spend the time (and money) properly protecting the 911 center.

As we move further into cloud computing, another option is emerging: Let the application owners decide at deployment. With tools like vCloud Automation Center (vCAC), we can define resources with differing service levels. An oil company I recently worked with integrated SRM with vCAC so that any applications deployed into Gold or Silver tiers would be protected by SRM.

2. Which failures are you preventing?

Each level of the data center has its preferred method of protection, although all areas also need to work together. If you’re concerned about preventing failures within the data center, maybe you rely on HA and App HA; however, if you want to protect the entire datacenter, you’ll need SRM and vSphere Replication (again, see chart).

3. RTO, RPO, MTD?

Another helpful step in choosing the best BCDR strategy is to define a recovery time objective (RTO), recovery point objective (RPO) and maximum tolerable downtime (MTD) for both critical and non-critical systems.

These objectives are often dictated by a contract or legal regulations that require a certain percentage of uptime. When established internally, they should take many factors into account, including if data exists elsewhere and the repercussions of downtime, especially financial ones.

The final step in the implementation of any successful IT strategy is not a question, but rather an ongoing diligence. Remember that your BCDR strategy is a living entity—you can’t just set it and forget it. Every time you make a change to the infrastructure or add a new application, you’ll need to work it into the BCDR plans. But I hope that each update will be a little easier now that you know the right questions to ask.

Want to learn more about building out a holistic business continuity and disaster recovery strategy?
Join these two great (free) webcasts that are right around the corner.

Jeremy Carter is a VMware Senior Consultant with special expertise in BCDR and cloud automation. Although he joined VMware just three months ago, he has worked in the IT industry for more than 14 years.