Alleviating database consolidation pains

Target Audience:

Most everyone I know have been in some kind of consolidation discussion, but as technical professionals many of us are not used to thinking about the business side of things. This session is aimed at the technical people involved in both deciding on consolidation and those tasked with it and can hopefully provide some ammunition to fire back at a non-technical decision to “consolidate” something.

Technically it’s a level 100, from a business perspective it’s more like level 150-200.

This session is 60 minutes.

Abstract:

Database consolidation was once described to me as a bit of a mix between the holy grail and a unicorn. Not that difficult in theory, but have a way of getting very messy in practice. Consider for example the meaning of “consolidate” – the number of potential issues stemming from not adequately deciding from the get-go what is to be done in the project. Classic issues include not knowing what we’re getting into, not having a goal(!), not adequately considering what systems (and how) will be affected, or not having the proper business processes to fall back on in order to decide on what’s actually important. In many cases a lot of issues stem from not having the same vocabulary and not considering the viewpoint of the “other” side.

I will go through these issues and more, and give technical tips as well as talk about business considerations like SLAs and how they can impact the choice of high availability.

At the end of this session you will have a good understanding of the challenges and solutions available for consolidating SQL Server primarily on-premise.

Why I Want to Present This Session:

As a consultant this is one of the more common scenarios I face. They usually go the same way:

  1. Client want to “consolidate” and “has done their homework”.
  2. I review said “homework” , point out a few hundred glaring holes and offer to go back to square one with a proper consolidation plan.
  3. Client decides that every system should have it’s own database.
  4. Facepalm

The clients that had me in for a talk like this presentation tend to behave somewhat different:

  1. Client wants to consolidate in order to reach a specific goal and wants help with doing a feasibility study to finding likely issues.
  2. The the study is concluded and most often the client moves forward with a much deeper understading of the ramifications of a consolidation project.
  3. An actual consolidation project is initiated with high chance for success.
  4. Profit

 

Session History

2017/04/30 – This session was voted into GroupBy June 2017, but Alexander had to withdraw due to scheduling issues.

The following two tabs change content below.
Next Post
Save Time and Improve SSIS Quality with Biml

4 Comments. Leave new

This is a great topic, and a very good abstract.
I got a little bit confused about how business-oriented vs. technical this session is, because in one place you wrote that “This session is aimed at the technical people involved in both deciding on consolidation and those tasked with it and can hopefully provide some ammunition to fire back at a non-technical decision to “consolidate” something”, while in another place you wrote “At the end of this session you will have a good understanding of the challenges and solutions available for consolidating SQL Server primarily on-premise.”
From reading the “Why I Want to Present This Session” section, it seems that by attending this session, I can have better chances of initiating and succeeding in a consolidation project. I would add that to the abstract, and replace “At the end of this session you will have a good understanding of the challenges and solutions available for consolidating SQL Server primarily on-premise.” with something like “At the end of this session you will have the tools and techniques that will help you initiate and manage a consolidation project successfully”.

Reply
Igor Castellanos
January 31, 2017 11:43 am

I think this is a great topic and you touch on some very important points, such as having a common vocabulary and a goal. I think your abstract would benefit from establishing a common understanding of the term “database consolidation.” Is it talking about reducing the proliferation of SQL Servers? Actually having more than one application pointing at the same database?

Reply

It is an interesting topic. I, unfortunately have exactly the opposite problem.
I hope you really hammer the concept of “just merge the tables and procs”. That is part of the situation I face. Lots of redundancy, duplication, overlap, inconsistent naming, yada, yada.

Reply
Rade Maskovic
February 7, 2017 9:05 am

Very interesting from a consulting point of view. So many different scenarios regarding customers and project goals and I would like to hear about what I could be missing out on. Life cycle management for SQL Server to avoid END OF LIFE after a successful project would also be cool to hear something about.

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

Menu