I was working with a client recently when an architect expressed disdain for a particular part of the SQL Server stack. In this particular case the architect had then chosen to roll-their-own solution which they felt was better. My intention is not to comment on their particular solution but it did set my mind thinking… do I let previous bad experiences cloud my judgment and adversely affect my solution proposals?
During my career I have worked with all manner of tools and products, I have worked with consultants and technical experts to work out solutions to complex problems. Now, in my role as a consultant it is important to capture a business’s requirements and map those onto technical requirements. By then designing a solution to meet the technical requirements it should follow that the business requirements are met. In the end, if I don’t meet the business requirements then project sponsors will see no value in the work I have done, no matter how hard I’ve worked, or how good my solution might be and the project will be deemed a failure.
One size does not fit all
If we consider a SQL Server related project, when trying to find solutions to technical requirements I always consider all of the options.
In a previous role I worked with transactional replication. Now, we had terrible trouble with our publication but that hasn’t stopped me from recommending it to clients where it has been the best solution to their particular requirement. For a slightly different requirement backup and restore might have been appropriate, always-on availability groups with a readable replica may have been a viable solution, using SSIS to copy data from A to B would have been another solution, but the best one for that client, at that time, was transactional replication. So even though I’d previously had some trouble with it, I was still able to recognise that it was the best tool for the job.
When it comes to technical solutions, one size most definitely does not fit all. There isn’t one way to provide High Availability (HA) or Disaster Recovery (DR) for a SQL Server database. There isn’t one way to build a data warehouse. There isn’t one way to design SSAS cubes or OLAP models. Indeed, if there was, my services as a consultant wouldn’t be in such demand. I can’t emphasise how important it is to step back and look at your problems without bias and pre-meditation. Only with a truly agnostic view can you design the best solution to solve a problem. Just because it didn’t work for you before doesn’t mean you shouldn’t consider it, and with regards to rolling your own solutions, just be sure you’re not re-inventing any wheels.
