Howard Dierking

In opening this editor's note, I want to make one thing painfully clear. I am first, last and always a developer. I can write T-SQL, but know very little about the various techniques for building clusters and administering the system. I can use declarative and imperative options for configuring Code Access Security in the Microsoft .NET Framework, but am at quite a loss when trying to configure my Windows Home Server to require a certificate for remote access. So what could I possibly have to say of value to readers of TechNet Magazine?

Over the last two years, I've developed a health obsession with the SQL Server BI stack. And in building a few internal solutions with these technologies, I've come to a conclusion that I think is worth sharing here as it reveals very necessary synergies and changes that need to be realized between developers, IT operations and the business.

In reflecting back over both business applications that I've built and applications that I've reviewed, it seems clear that software development as a general activity is optimized around building transactional applications. Reporting capabilities are generally bolted on top of a highly normalized relational database that was never intended to provide any level of insight beyond the record of transactions. In other cases, the transactional database may be designed in an attempt to support both transactional and deeper reporting requirements—in my experience, such systems are not generally successful at either.

While it seems that this may be a developer problem, I bring it up here because in several of the conversations I have had with developers about this problem, the justification that I have been given time and time again has been that IT allows one—and only one—database. So my request to you is this—stop giving us that excuse. Whether it's working with development to plan a separate, isolated reporting store or whether it's upfront integration planning for a larger warehouse, I ask that you impress upon the development teams the notion that this separation of concerns is one worth doing. Remember, we developers tend to optimize around the transactional piece—so without a friendly push in the right direction, the path of least resistance is to ignore everything but this piece until it may be too late to do much about it without practically rewriting the application.

At the risk of making an overly broad generalization, you have a broader perspective when it comes to the business—after all, BI is generally considered an IT Pro activity. However, putting the pieces together is still very much a development activity. So use BI as a way to help broaden the perspectives of your developers. I'm sure they'll be grateful—and if they aren't, you can at least know that I'm grateful.

—Howard Dierking

Thanks to the following Microsoft technical experts: Steven Bergman, Ryan Donovan, Corey Hanson, Ken Jones, Denny Lee, Sanjeev Nair, Chad Rexin, Stefan Schackow and Kimberly Tripp.