When I wrote the blog SSIS # 102 – Don’t be afraid to leverage TSQL in SSIS package, it was purely “inspired” by an ETL design I was working on during the day, and also an SSIS training piece I was reading from Pragmatic Works.

However, I was pleasantly surprised by some comments about my blog from the readers.

Here is one:

No… I’m not badmouthing SSIS. I’m looking for someone to give me a good honest answer to give me incentive to spend valuable time learning to do something a different way when I already know of a good way to accomplish ETL for millions of rows per batch in a very high performance manner.

Here is another one:

I’m afraid this may become a religious issue. When there are a number of ways to do things, some better in some situations, others better in other situations, it can become a messy conversation.

I can tell that both comments come from somebody who already has significant amount of experience in their own profession.

I have been thinking about these two comments for a few days now.

These two comments seem to be un-related at the first glance.

The first reader seems to be needing some more persuasion so he (or she) will be willingly spend time to learn SSIS (and other BI tools).

The second reader is reminding me of the sometimes contentious discussion among developers, i.e. the all SSIS solution Vs. the all TSQL solution Vs. the mix. I used to work in such a development team. The lesson I learned from that experience is that it’s the end result that matters. I was able to deliver an ETL solution within the deadline with a mix approach of SSIS and TSQL (meaning procedures). Another developer was also able to deliver his portion of the ETL solution with 100% hand-coded TSQL. However, the developer who insisted on SSIS only solution failed to deliver. But the failure is totally un-related to our discussion of SSIS Vs. TSQL. The failure is because the developer totally underestimated the complexity of the data.

You might wonder where I am heading in this blog. What I really want to do is to convince the first reader to start to learn SSIS NOW.

I don’t want to go into technical aspects of SSIS Vs. TSQL. There are plenty of resources out there that have done an excellent job explaining what SSIS can do. What I want to say is totally non-SQL, and non-technical, and also very simple. The world is evolving. I was an application programmer, then database administrator, then SQL developer, then SQL developer with BI skills. I was forced to evolve along the way, because as an independent contractor I had no one stable job I can go to every day, every month, or every year.

The second reason for the first reader to start to learn SSIS (and other BI tools) NOW, is the point the second reader is making. The more skills you have in your toolkit, the more chance you will have to succeed in your career. Forget about the religious issue, the messy conversation. We need to focus on enhancing our skills and collecting valuable tools for our toolkit along the way.

I will be very happy if the first reader one day will decide to join the Microsoft BI bloggers…..