Wednesday, July 25, 2012

Agile BI and Why the BI Admin Needs to Care

The top priority of a BI Administrator is to keep the BI systems up and running and running well. This is the primary area of overlap with the traditional DBA role. Every DBA knows that the best way to optimize performance of a database-related system is to design it right in the first place.

The great thing about the Microsoft SQL Server platform is that, compared to other DBMS and BI platforms, it is really easy to manage. The benefit to this, if not Microsoft's explicit intention, is that the DBA/BI Admin has more time to work with developers to enable and encourage them to build the best solutions they can.

I recently forgot the importance of this Admin-Developer relationship and it is causing a bit of grief.

Where I Went Wrong

The one and only thing that went remotely bad with our SQL Server 2012 upgrade was my communication and preparation for the development teams. I spent a boatload of time making sure the end users wouldn't be affected by the upgrade but I didn't do nearly enough legwork making sure our BI developers were ready for the upgrade.

Our BI developers are really great but I underestimated the amount of confusion that moving from the SQL 2008 R2 development tools to SQL Server Data Tools in SQL 2012 would cause. As a result, we are in a bit of a limbo state on how we need to adjust the way we build our solutions with the new tools.

The moral of this story is this: If you enable developers to do things right you'll spend a lot less time fighting fires; if you don't, you'll be surrounded by fires. I'm not done yet though. I haven't mentioned where the Agile part of all this comes in.

You Can Interrupt Agile

To enable your developers to make the right technical decisions, you have to know and understand how they work. This is ten times more important when your development teams are following Agile principles. Sure, being Agile means you can handle change better than with pre-Agile methods but the problem you run into with Agile teams is that they are more susceptible to short-term disruption in their processes. Agile teams get into a groove and they get used to delivering new functionality quickly. When you introduce a change in the process it slows them down and they don't like that (neither do their customers). Even worse, if you need to make a change to the process but you don't have a clear understanding of what the change needs to be, you can really screw things up.

The difference between a DBA and a BI Administrator is that a DBA should be a developer while a BI Admin must be a developer. BI solutions are more than just databases. They are the life blood of the decision making process for a company. The BI Admin must be ready to enable the BI developers. This means knowing their processes so you can help streamline them and this is where I fell short in our upgrade plan.

Time to Get Better

It is time for me to learn to be Agile. In some ways I do Agile but I don't really know how our development teams operate. I made an attempt to join one of our teams for one iteration. It didn't go very well. I was pretty new to the Business Intelligence team (and the company) and getting my DBA-type ducks in a row was of higher priority at the time. I have come to learn, however, that becoming truly Agile may just help me get those ducks in a row and keep them that way.


Learn more about Agile BI from Ken Collier at; in particular, check out his article Being vs. Doing Agile. I will have some more to say about the subject in the near future as well. Please feel free to leave some comments telling us about your experiences with Agile BI.

1 comment:

  1. This is true because these things have a lot of importance when we see how we can understand and take it to the next level,Most of the times stuff like agile business intelligence give us an appropriate outcome so we can get to understand that and this is the way for that in my opinion.