Microsofts VSTS Goal: Creating a Mass Market for Enterprise Tools (
Page 1 of 6 )
In an eWEEK interview, Rick LaPlante, general manager of Visual Studio Team System at Microsoft, shares his views on Microsoft's strategy for the new tool, competition with market leader Rational, and why Microsoft is not so keen on UML.
Rick LaPlante, general manager of Visual Studio Team System at Microsoft Corp., sat down with eWEEK Senior Writer Darryl K. Taft to share his views on Microsofts strategy for the new tool, competition with market leader Rational, and why Microsoft is not so keen on UML.
In a separate interview, Rationals Grady Booch discusses the new competition from Microsoft and Rationals development strategy going forward. Click here to read the interview.
Im curious about the origins of this [Visual Studio Team System] technology. When I was trying to find out what it was prior to the announcement, all I could get was that with this product, Microsoft was going to show why it didnt buy Rational. [It has been widely suggested that Microsoft was an initial suitor for Rational, but neither Microsoft nor Rational has ever commented on this.] So, is that the case?
In June of 1999, I was responsible for driving the business strategy for the tools division. And we had done a deep strategy review of where were the problems left for our customers in this space.
I mean, we clearly had been shipping a world-class development environment, really focusing on developers, and the core, big, pressing dimension to our product strategy was teams—or going from developer to focus on development. And we coupled that with the view of Microsofts strategy in the enterprise space—moving much more into an enterprise mission-critical role.
And so, we were seeing the servers getting the adoption, and we were seeing the reliability and security and those sorts of things coming up to speed where we were getting enterprise development. And we were starting to see customers asking for sort of the coupling of the tools with that new style of development—the systematic development, the less opportunistic development.
We said at the time that we needed to extend our product line to address that market, which really is defined as an uninteresting or noninnovative market, in terms of what the industry or the "enterprise tools business" had been doing over the past 10 years.
And so, thats sort of where it started. It was definitely a business look at how do we make our customers successful as we transition into much more of an enterprise provider, with a server infrastructure and with the programming model. So, moving from a developer focus to a development focus and team focus was a critical piece of that. Thats where it started.
Click here to read more about Visual Studio Team System, aka "Burton."
Well, how much of a "sell" do you have to convince customers that Microsoft is capable of delivering this, a server product?
Thats a great question. Ill answer that in two ways, largely connecting it to what I just said. When we looked at it, we said, well, there are people in this space already, and we have lots of partners in this space. Why is it that we think theyre not meeting customer needs? And what is the definition of the opportunity here? And the definition was to really, dramatically increase the predictability of success.
And so we were seeing, when we started doing customer visits, and we did hundreds of them during 1999 and 2000. What we were seeing was a lot of shelfware in terms of this type of tooling—so a lot of people have the licenses, not a lot of usage.
We were seeing a fair bit of passive-aggressiveness. In other words, the management teams would say, yes, we are using X, Y and Z, and we have great processes. And the engineering teams would say, are you kidding me? So, there was a fairly big disconnect between the engineering disciplines and what the management expected was going on.
And we had a lot of customers question the return on investments in their spaces, both in terms of the very high initial acquisition costs and some of the ongoing costs around support and maintenance. And were they getting the value, because there was this disconnect between what the management thought was going on and what engineering was doing.
And what we decided was the critical missing element there was an enabling level of simplicity.
In other words, how do you allow an engineering team —and I dont mean just developers, but developers and testers and project managers and architects—how do you allow them to do their jobs in a way thats fairly consistent with what they do today, but at the same time easily communicate, hide the level of collaboration necessary to get everybody to the same point at the same time?
Next page: "Friction-free" data flow.
Web Services, Web 2.0 & SOA 
