Experience is the best teacher, especially when you're deploying new software. But when a software product is newly available, how do you find somebody who has already deployed it so that you can learn from his or her experience? Well, for Microsoft software, you can learn from the company's own IT organization, which works with all Microsoft products while they are in development. Take SQL Server 2005 Reporting Services, for example. What lessons did Microsoft IT learn by deploying and using Reporting Services during the product's development? We took that question to Microsoft executives Ron Markezich, chief information officer and vice president of managed solutions, and Stuart Scott, corporate vice president and chief information officer. For the technical perspective on deploying Reporting Services 2005, we also talked with Microsoft Business Unit IT Development Manager Frank Schneider.
Double Jeopardy IT
KF: Running an IT organization for a major company is a big job in itself, but Microsoft IT also has to be "the first and best customer" of Microsoft's software products. Ron, like any CIO, you and your team are responsible for using Microsoft technology to increase Microsoft employees' productivity while decreasing the cost of IT. Unlike most CIOs, you're also responsible for ensuring that Microsoft's customers benefit from your experience with the company's products. How does that work?
Ron: My main responsibility is to make sure I'm running business [i.e., IT] on our products before we ship them.We call that "eating our own dog food," or "dogfooding" our products. Microsoft will not ship a product unless we sign off that the product is ready and is high quality before it ships.
KF: Does that mean the company's expectations for IT productivity are adjusted when you're dogfooding a product, such as SQL Server?
Ron: Even when we dogfood a product, I don't get more budget or reductions of my Service Level Agreements (SLAs). I don't have fewer apps to create. The business expectations are the same as when we're not dogfooding. The company still expects me to take down cost per app, add more value to the business, reduce support costs so I can spend more money on development, and have a secure environment. Expectations increase every year; and can increase when we're dogfooding, as well.
At the same time, I work closely with the product development teams. The SQL Server developers, for instance, might call us and say they have a new build coming next week and want it deployed within a day to get feedback. So when we receive a new build, we need to deploy it quickly across our environment.
Meanwhile, our people are doing development work for the business, so we have to balance that. People in IT work extremely hard during the dog food season. They really do two jobs—they're testing a product and meeting business needs.
I don't think we're any different from any other IT shop. One thing dogfooding helps me do though—it aligns my IT organization closely with the mission of the company because IT is not a cost center; it's part of the process for shipping our products to customers. That's wonderful for any IT organization because people become part of the product. We add a whole new level of value to the company, and that's why people are willing to work so hard during dogfooding.
KF: Stuart, as someone who just joined Microsoft in July 2005, what was your impression of the dogfooding process?
Stuart: I was surprised at how much we used SQL Server 2005 in production with high-profile, business-critical applications. I was surprised by what we dogfood—SAP, CRM, and ERP systems. Couldn't we find something a little easier?
I came from a non-Microsoft environment. I realized we had worked awfully hard there to pull together an integrated solution through a lot of open source and other third-party tools. But the productivity of my engineers here versus my previous experience has made me a convert. Our development cycles here are much shorter. I wasn't looking for that, but it struck me the first time I did a project review. Developers were talking days and weeks, whereas in that scale of system, I'm used to months and months of development.
The Environment for Serving Dog Food
KF: Stuart, you're responsible for design, development, and deployment of IT systems. Can you describe Microsoft's IT environment?
Stuart:We have 2,500 applications, and the infrastructure includes more than 220,000 networked devices supporting over 90,000 employees and contractors, making it one of the largest corporate technology systems in the world.
KF: How do you roll out a new version of a major product such as SQL Server 2005 in that environment?
Ron: When a new version is in development, we start using it in test labs in the Alpha stage and roll it out to production at Beta 1. But even before that, we sit with the product team and define shared goals.We will not ship the product until those goals are met.
In the case of SQL Server, it is the only database we use. IT manages and runs roughly 1,500 LOB applications—anything from a sales force automation application to a payroll application—on SQL Server. We put our SAP production application on SQL Server 2005 in August 2004. By the time the product shipped, it had been running for 15 months in production. This is the same production system that does all of our US payroll and benefits, recognizes all of our revenue, does a lot of our management reporting, and all of our general ledger and accounting.We trusted SQL Server 2005 on our most critical applications.
Reporting Services 2005: Lessons Learned
KF: You mentioned management reporting. Tell me about Reporting Services 2005.
Ron: Reporting Services is huge for us. Microsoft is a data-driven company. Our reporting environment uses a lot of Excel templates and standard reports. In the mid-1990s we consolidated our disparate financial and reporting systems into a common platform, which exposed a lot of data through Excel reports. The problem was managing these reports. It was hard to drill from one report to another and to manage them. Reporting Services makes managing standard reports easier and allows drill-down across reports tied directly to the database, so you're always getting the data off the database.
KF: Can you give examples of how Microsoft uses Reporting Services 2005?
Ron: We have thousands of P&Ls because we look at finances by geography, as well as by product and channel. We let Microsoft business units in a particular country look at P&Ls by their geography and then drill down to their country and view by channel, by product, by customer. That capability used to require a lot of different standard Excel reports. So files got very large. You had to pass them around the network.
We've moved all those Excel reports to Reporting Services, which uses less bandwidth because you're not sucking down those 40MB Excel reports. Also, we used to manage all the versioning, templates, and generation of those reports, and now Reporting Services does that for us.
Now we can integrate reports and drill down from one report to another. Users can choose to get a report in the Reporting Services browser or in Excel, and they still have the drill-down capabilities in Excel. People like Excel as a front end because sometimes they like to go outside the report and do some calcs directly in Excel.
KF: How did you roll out Reporting Services 2005 in your department?
Ron:When we roll out new technology, we work through our IT teams that support individual functions such as finance, HR, sales, and marketing. We set up multiple sessions with the developers from each IT team and explain what's in the product and the value they'll get. They take the information we provide back to their business and start mapping the product's components to the problems they're trying to solve.
So in the Excel example I gave you: All of our broadly used and most critical reporting systems are using Reporting Services—like our in-house Management Reporting System (MARS).
KF: Frank, you're the development manager for the IT team that is responsible for MARS, right?
Frank: Yes, we are the IT team that supports finance in addition to corporate accounting. Because the company's reporting is broken down by region and function (primarily for security reasons), you had to have multiple reports querying the SQL database. We had more than 100 reports. With Analysis Services and the security policies we applied, we can now have one report of each type serve all regions or all functions, and Analysis Services handles the security credentials of the report owners and gives them only the data that their division should see. So you don't need 20 different reports, which were basically one report sliced 20 different ways. So that's a big improvement.
Prev. page
[1]
2
3
next page 
