eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
Page 2
How early on do you get involved? When do you see the products?
As early as possible. We will typically start running products like this a year and a half before release. Ill give you a couple of examples. On SQL Server weve been running our SAP system—we have one instance of SAP that does financials, payroll, benefits, management accounting, all of that worldwide, and weve been running that on SQL Server 2005 in production since August of last year. And we had smaller applications on SQL Server 2005 earlier than that.
Visual Studio as a dev platform has been our standard now since the beginning of the calendar year. All new development is being done on Visual Studio 2005.
And you use the Team System?
Yes. Actually, to tell you the truth, Team System is the area thats probably having the most benefits, because of the compliance pieces. Thats been the most dramatic change for us.
Whom do you go to for support for these products, the product teams or elsewhere?
While were in beta we go to the product teams. In fact they work super closely with us because any issue we find they want to make sure it gets into their next build as quickly as possible. Once the product goes to general release, then we go through the normal support channels—we go through our customer support service just like any other customer would.
So youre like an additional part of the development process early on?
Yes. In fact I look at my organization as being an extension of the product teams. Before a product ships I have to sign off on that product saying that we run our business on it. So we wont ship an enterprise product unless were running Microsoft on it and I sign off on the fact that we are.
How big is your organization?
We have about 2,000 employees and another 2,000 vendors. Vendors would be where we outsource—like we outsource our call center, and we outsource some of our application development.
Have you tested Longhorn or Office 12? Are you working on those?
Yes, were working on that as well. So one of the things there … in this stage, just like we did with Visual Studio and SQL Server, we sit down with the product teams and we sign up for shared goals before we start testing the products. And we track those shared goals throughout the process, and then before that product can release that product needs to meet all of those shared goals. So with Office 12 and Longhorn were defining what those shared goals are.