Whether you need to have a good network connectivity, a tight integration with Active Directory or DNS, a stable Windows Server Failover Cluster, etc. the most common advice that technical experts will give you regarding SQL Server Always On Availability Groups falls into one category: technology. I’ve just listed a handful of them and there’s still a bunch more. I’ve been guilty of this myself whenever I get invited to join a technical call to assess a customer environment. I guess it’s but natural: “geeks talking geeks.” Have you ever been invited to a party where everyone is talking about something which you know nothing about? Duh!

When a customer or your manager approaches you and ask about this new SQL Server feature called Always On (I really don’t like calling it Always On but that’s how I can communicate with them) pay attention to your initial response. I bet you would start talking about the technical details of the feature – having multiple copies of the database, faster failover, automatic redirection, readable secondaries, etc. There’s nothing wrong with that. However, when you start off with the technology aspects of a feature, technology will end up dictating the direction of the conversation.

So, What Should Technical Experts Be Telling Me About SQL Server Always On Availability Groups?

I’m glad you asked. The answer to that is simply this:

 DESIGN should be driven by requirements, NOT technology

It’s interesting how a simple phrase like this changes the tone of the conversation from technology-focused to requirements-focused. I confess that I still struggle with it on a regular basis. But I try my best to refocus the conversation from technology to that of requirements. Here are a couple of questions you might ask during a conversation:

• – Instead of asking, “Do you prefer a failover clustered instance or an Always On Availability Group,” try asking, “how much downtime can you afford?“

 

• – Instead of asking, “How many replicas do you need for your Always On Availability Group,” try asking, “how much data can you afford to lose?“

 

• – Instead of asking, “Do you need 24 x 7 availability,” try asking, “what was the agreed upon service level?“

If you start asking non-technology-related questions, you start to uncover more important aspects of the business that may not have been discovered had we focus on technology. One example I can think of was when one of my previous customers asked about Always On Availability Groups in relation to their SharePoint 2019 environment. While the SharePoint farm is mission-critical, it is only accessed during normal business hours within the North American timezone, roughly between 7AM Eastern time to 7PM Pacific time Monday to Friday. This means that they have a 9-hour maintenance window during the weekdays and more than 48 hours during the weekends. While they started asking about implementing Always On Availability Groups for their SharePoint 2019 farm, I recommended that they simply implement a 2-node failover clustered instance since they already have shared storage anyway. For disaster recovery, they can just use log shipping. This design was enough to meet their business requirement. It even saved them big time on licensing cost because Always On Availability Group is only available in Enterprise Edition. They were able to implement a 2-node SQL Server failover clustered instance using Standard Edition.

But the point simply is, let the business requirements dictate the design and implementation of a technology solution and not the other way around. As a technical expert, resist the temptation to start and lead the conversation towards the technical aspect. Focus on the business requirement to define the appropriate technology solution.

To help you even further, I’ve recorded a video that highlights the different acronyms (I also call them the Alphabet Soup) that need to drive your high availability and disaster recovery solutions – be it implementing a SQL Server Always On Availability Group or any other technology.

Schedule a Call