As you go thru different phases in your career as a SQL Server professional, you progress from being a technician (primary task is more focused on operations) to a designer/architect (primary task is focused on designing a solution and eventually assists in building it.) A technician will be more concerned about a single aspect of a solution whereas a designer/architect will be concerned about the entire solution.

A common question that I get asked from SQL Server professionals when doing presentations is this: “How do you get more experience designing a solution when my current role does not have enough opportunities to do so?” My typical response is summed up in the statement below:

You become one when you start thinking like one. Share on X

This statement applies to just about anything you can think of.

• – You become an architect when you start thinking like one.
• – You become an engineer when you start thinking like one.
• – You become an consultant when you start thinking like one.
• – You become a writer/blogger when you start thinking like one.
• – You become a CEO when you start thinking like one.

Change starts from within ourselves. When I was working as a data center engineer, I didn’t see my role as simply that of a data center engineer. I saw myself as a consultant – one that provides a solution to a problem. I saw myself as a project manager – one that defines the different aspects of a project implementation and manages scheduling and resources. While my official title is still that of a data center engineer, I thought differently and acted differently. Because actions follow our mindset.

You might be asking, “What does this have to do with designing a SQL Server Availability Groups topology?”

A high availability solution like that of SQL Server Availability Groups depend so much on a lot of moving parts. Simply implementing it is not enough to meet the business requirements.  It requires a totally different mindset altogether. Which means thinking outside of the “SQL Server box” and looking at the different components that will affect your design.  When I recorded my very first SQL Server Availability Group video, those who have seen it thought that it was easy as clicking a few options, enabling a few features and configuring it. Little did they know that there were a lot of components that needed to work in order to build a working solution.

This video recording of a webinar I did a few years ago will get you started on how to design and architect a SQL Server Availability Group topology. It challenges you to think differently – to start with what the business needs and focus on a solution that will meet those needs. It also considers the common design patterns that you will see in the field and how I look at each of them with the business requirement/s in mind. My goal is not just for you to become a better SQL Server professional and progress in your career. More importantly, I want you to change the way you think about approaching problems. Because, sometimes, we don’t really need better solutions. We just need a better way to think about and look at problems. You might be surprised that the solution you’ve been searching for is right around the corner.

Enjoy watching the webinar recording.

Schedule a Call