Microsoft IT Relies on Home-Grown Products—and Vice Versa

In an eWEEK interview, Microsoft's CIO says the company typically starts using its own products a year and a half before general release, and no product gets shipped before he signs off on it.

/zimages/6/103041.jpgMicrosoft Corp. uses in-house its own technology such as the upcoming Visual Studio 2005 and SQL Server 2005 products—the integrated tool set and database products Microsoft will be delivering simultaneously later this year—even before they ship to the public. Ron Markezich, Microsofts chief information officer, discussed with eWEEK Senior Editor Darryl K. Taft not only Microsofts IT environment but how it is part of the Redmond, Wash., companys development process.

/zimages/6/28571.gifFor more on the integration of SQL Server 2005 and Visual Studio 2005, click here.

Can you describe the Microsoft IT environment and how your organization plays into the development scheme at Microsoft?

Let me give you a little bit of context for IT at Microsoft. About two-thirds of our total IT spend is on applications—line-of-business applications—and about one-third on infrastructure. And if you look at the trend over time, what were doing is decreasing our infrastructure spend quite a bit and driving the increase in applications spend, because were looking at line-of-business applications as areas where can create competitive advantage and provide new business value.

We typically use very few packaged applications. We have a few core packaged applications, but if you look at the total amount of line-of-business apps, about 75 percent of that is custom app development, support and maintenance. So we use Visual Studio and SQL [Server] as our core development platform. Visual Studio is our dev platform; SQL Server is our database. We dont use anything but. So we use it quite extensively.

Some of the areas where were getting value … The integration in terms of the development suite is one. Traditionally we would have applications developed in SQL [Server] using stored procs [stored procedures]. The difficulty for me there is you have all these stored procs that youre managing and you have to modify and support on an ongoing basis. But also from a compliance and controls perspective its difficult because we have a common Software Development Lifecycle [SDLC] that has appropriate control points throughout that process. Now … with Visual Studio Team System we can embed that SDLC process within the development platform.

So for me as the CIO, one of the things most beneficial for me is the compliance aspect—compliance to our SDLC and compliance to our internal controls.

The other piece is developer productivity and increasing the productivity of our dev team. So were seeing a good increase of productivity where the development work is becoming a smaller percentage of the overall time spent on the solution. Most of the time is really on the requirements gathering and the system design; the development is a smaller piece.

The third area is the consolidation for us. Im talking about database consolidation, as well as consolidation around some of our data sharing. What the products are really enabling us to do is move to a services-oriented architecture [SOA]&151;away from what weve traditionally had, which was really a batch architecture and batched data across the company, which doesnt do much for me in terms of consolidating my applications and ensuring compliance with the data that I send, and the audit trail of that data.

So having that consolidation of applications saves me money, reduces my complexity and helps me with my compliance.

So what is it thats delivering the gains in developer productivity? Youre able to cut coding time, but you do more on requirements?

We spend more time on requirements as a percentage of the total solution. So this doesnt force us to spend more time on requirements. You can never spend enough time on requirements, thats probably where things get overlooked the most. The productivity components, if you look at Team System and the Web services embedded in SQL Server, they give developers additional productivity capabilities.

A good example is SDLC. Because we can use Team System and embed our control checks in SDLC, it ensures consistency across all the applications, rather than having the developers understand, When do I need to implement a control check? They can use the tool to guide them. Thats productivity because in the past you had to go back and review your application and make sure you had the appropriate control checks.

The Web services component as well … the ease in which you create your services is tremendous. Its like when you used Visual Basic to create user interfaces; its getting to a point where you wont even need an IT person to create your services because you can leverage a less technical person to do that.

But its the integration thats enabling that? Because youve always had the same tools, or at least access to Visual Studio.

Oh yeah. Visual Studio has always been our dev platform. Just like SQL Server has. But if you look at the challenges of the past, you had a group of people that were SQL Server dev folks, and you had a group of people that were Visual Studio dev folks. And you lacked that integration between the applications.

Next Page: ITs early involvement.