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:
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.