eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
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.
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.
Friction
-free data flow “>
And we came up with the notion that we call the friction-free flow of data. And that was the critical element of what we saw was lacking in the industry. How people either had to change their work style or in fact how they had to repeat the same processes multiple, multiple times in order to get from one tool into another tool. And when you take people out of their … almost a stream-of-consciousness workflow, then you increase the risk that they dont do it or they dont do it well.
And in our notion of this friction-free flow of data was—in the context of what people were doing, in the context of a developer fixing issues—we need to be able to track what the requirements are, what the test cases are, what code coverage, and whats the quality and those types of things.
And so our first high-order business differentiation was people will use it—that the impeding mismatch between the engineering teams and the management teams, you cant say it goes away but it is drastically smaller. And thats what were seeing in the feedback weve gotten from Tech Ed.
So, having said that, do I think we have an uphill sales model? Yes, but not for that reason. I think we have an uphill sales model because people dont expect this type of tooling from Microsoft. Its much more of an awareness issue, I believe—and thats sort of my mental model—than it is a technology issue or a belief-that-we-can-deliver issue.
And what weve seen is as we get people—Ive been doing a ton of customer visits and people have been coming into Redmond and Im flying around—and the reaction is, “Wow, we had no idea you were doing something like this; when can we get it?” So, its much more of an awareness challenge for us than I think it is a technology challenge.
I dont know what you need to do to sell, but just providing the technology could be enough to cause inertia in the market.
Weve gotten a lot of feedback from analysts and they have been bullish. I think customer value gets created in a ton of ways with us being in this market. And one of them is directly through the tooling, through what were doing. But the second one is our goal is to create a mass market for enterprise tools.
Ill assert that that is an oxymoron. There isnt a mass market for an enterprise tool. The data that we have is the largest independent vendor of enterprise tools is homebuilt. So, we need to get people aware of the value, of the importance, and in fact of the ease of use.
That it doesnt have to be this huge learning curve to go from your developer-centric engineering tools to the monstrous sort of process where you have to relearn everything, including your existing workflow. So, we think if we can smooth that curve—instead of making it this huge step as it is today—that well deliver real customer value.
And we think theres going to be a lot of innovation in this market. People are going to look at what we do in many dimensions. Partners are going to pile on what we do. We have a lot of partners who never had suites, but who had best-of-breed, world-class point tools. I think that they will integrate into the suite, and then they get to be part of a suite that they never had before. I think theres a lot of customer value driven that way.
Quite frankly, IBMs going to do interesting stuff based on what were doing—theres no doubt. And a lot of people are going to react to our entry into the market, and in the end it just drives tremendous customer value.
Next page: Building a platform first.
Building a platform
first”>
Good segue. Im curious about what kind of ecosystem this will foster. In what ways will it bring stuff out of other people including partners and competitors?
That was probably one of the hardest business issues. For the first two years, it was less about the technology and more about the business model. … One of the hardest or most challenging business-model decisions we had to make was, “How do we enable our partners to participate in the rising tide?” And so we started very early on with the strategy of not really building a set of tools, but building a platform. That resonated well with us because we get platforms. We understand how to be a platform; its what we do.
So one of the first strategy decisions we made was that the team system was a platform first, a … tooling infrastructure, and then a set of tools that we built on top of it.
So the design point, very early on, was we will expose everything we use. So the collaboration between the client side and the server—and sort of our integration layer—is completely Web service-based. We will make it completely available. There are no back doors that were using; therere no protocols, theres none of that stuff. So we did that; and sure we had challenging discussions when we started doing private briefings, and then when we got everybody together in November of last year.
So in November when we first brought the partners in for the first time, two things were pretty interesting about that. The first one was, we were a year and a half from shipping and we were fully disclosing what we were building to everyone, including IBM. IBM was there; theyre a very good VSIP [Visual Studio Industry Partner] partner.
Also, Mercury [Interactive Corp.], Borland [Software Corp.]—all their people were there and we were disclosing where we were going, that we were coming into this market, what we were roughly building, and that our intention was to build a platform.
That was very risky, but it was absolutely the right thing to do because we are first and foremost a platform company.
So I think that that was a great start. It was a challenging set of meetings. And if you talk to people youll find it was a challenging thing for people to hear. And it was like the 10 phases of grief. We worked through that to where now we have people saying; now we get this. We get what opportunities there are. We get how were going to play in this world. We get how Microsoft is going to create a mass market and those types of things.
So I think the existing partners all have some interesting opportunities with the Team System. But I also think that the ecosystem will evolve in ways weve never even thought of. For instance, Ive had several people talking about building-process guidance. Because our tooling is completely configurable via an XML document that configures what we call a methodology template that can fundamentally change the behavior of the tooling.
If you were to use an agile method of the methodology versus a formal version of the methodology, you almost wouldnt recognize the tool. You certainly wouldnt recognize the process. And so I think that people are going to create methodologies and sell them or open-source them and put them out on the community. I think people will build a ton of add-ins, because I think about the component world, where we have base functionality in the platform for things like “eventing” and notification.
Somebody will build a really neat tool that sits on top of our reports and fires off a report any time an event threshold is crossed. So, there is just a ton of opportunity for people to fill in very interesting components. There is a list 30 things long that I wish we could have done—I think partners will step up and provide value by selling those things, too. So its not the existing business model that theyre in, but I think theres a ton of new opportunity opened up because of the platform thats the team system.
The UML challenge
Can you talk about what SKUs are going to be involved?
Yeah, we think that there will basically be … Were moving from developer-focused to development-focused, so were going to introduce role-based SKUs. So well introduce Visual Studio Team Architect, the Visual Team Developer and the Visual Team Tester. Thats to say thats what were introducing for the first version. And you could imagine there are many more roles in the product lifecycle, so you could imagine that expanding over time.
But for version one those are the three role-based SKUs. Assume that there is a way to purchase them together, so a bundle or suite or that type of thing. Then the other one that is of super-high interest is the Team Foundation Server itself. And that is a separate SKU; its a server-based SKU.
How do you plan to support UML [Unified Modeling Language] in the platform?
Thats a good question. The way I think about UML is UML is an interesting set of designers in a metamodel for a set of challenges you would face during development—class design, sequence design and those types of things. Moving up into more of the “what” instead of the “how.”
The challenge that we have with UML—and I think its certainly as long as Ive been over the last four or five years in this business running the Microsoft enterprise tools business weve been consistent with this—is that UML is a good set of tools for a certain set of problems. But it reminds me of the old adage: If you have a hammer, everything looks like a nail. UML has an extensibility model that allows you to describe other, what we would call, domains. Like things like BPEL [Business Process Execution Language] or Web services for that matter.
The challenge with the UML model is everything has to be described in the terms of what UML already understands. And thats kind of like saying a thumbtack is like a nail. So I want to talk about the world of screws. So its like a nail, except you dont use a hammer; its either Phillips or regular and its got threading and their national standard or other. So thats an extensibility model for UML.
We actually believe that there is a better way. And we didnt make this up, quite frankly. The better way was thoroughly described by the SEI [Software Engineering Institute] out of Carnegie Mellon [University] as domain-specific languages. The notion of domain-specific languages is that you shouldnt say a screw is like a nail except for all of these different things.
What you should do is you should precisely describe a screw. And so instead of having one nearly monolithic metamodel that you map things into that you basically use profiling to describe things as, we think you just describe them precisely as they are.
So, if for instance you have a Web service and you want to describe a design experience around Web services, you should use a precise definition of WSDL, ASMX, proxies, ports and those types of things. And you should precisely define those things. And you shouldnt say a port is like a class except for it has all these other properties—because it kind of is, but mostly it isnt. So thats the challenge I have with UML.
Our stance on UML is it has a very interesting set of designers for a certain set of problems. And with the engine and the infrastructure that were building, you can render the full UML metamodel. But it is one of, not the only.
Next page: Trip-less vs. round-trippers.
Trip
-less vs. round-trippers”>
So UML support will be provided through Microsoft or through partnering?
We will do some of them. … And it depends on if youre talking about UML 2.0 or UML 1.4.x. For UML 2.0 we will certainly rely on partners on our platform, building on our infrastructure to deliver a full UML 2.0 implementation. And we will deliver some of them ourselves. So we will certainly continue to deliver the Visio modeling tools that we have, which are UML 1.4 compliant. So well continue to deliver those tools.
And then the strategy is to take the key domains out of the UML model that we think are really critical. And there are some of them. Like “use cases” is very interesting. Its a very interesting domain in and of itself, so we think that over time we will build use-case designers directly into the tooling. And then there are some that will look like what UML produces but are in fact domain-specific.
So let me give you an example—the sequence designer. In UML they have a generic sequence designer for designing sequences of integrations between anything. We have the notion of a WSDL contract designer, and it has very specific semantics because WSDL has very specific semantics. It looks a lot like a sequence designer.
We will not ship that in the first version, but when we do ship it people will look at that and say, “Hey, thats a sequence designer.” Well, it mostly is a sequence designer, but it has very specific semantics towards a problem domain.
Now, why should anybody care about that? Here is the one gem I have learned in the five years of dealing in this space, from some incredibly smart people weve got that have been working in this problem space for 20 years. And that is that the closer the underlying representation is to the model, the more likely it is that you can have a trip-less experience.
And the notion of “round trip,” which UML talks about, I think is just wrong. I dont want round trip, I want trip-less. I want the relationship of a view to a database table. It can never be out of synch because its just a view of the same data. Thats what you need to get to from a tooling perspective to make this stuff work.
And thats why, quite frankly, people dont use UML. They may use it to document, they use it to do some initial design, and then it goes by the wayside. And I think, with all respect to Grady [Booch, co-creator of UML], I think were a long way away from executable UML.
And the challenge is because there is such a transformation in the semantics, between the underlying implementation into a UML model, that isnt exactly precise to that domain. So the closer you can get your domains [to] those underlying implementations, theyre just views of the data and that works. And when that works people will use it.
I came from the world of writing C++ compilers. Im not a modeling guy. And when I think about the world of the promises of CASE, Im exceptionally skeptical. I was at Microsoft in the late 80s when CASE tools were going to be the thing. And they never materialized because of this disconnect between implementation and the metamodel, and the cost of keeping those in synch.
So if you can solve that problem then I think you have a world-class designer strategy, which is where were going, and which is what we think the domain-specific language approach—again, not invented by us—actually enables you to do.
Next page: Defining domain-specific languages for Web services.
Defining domain
-specific languages for Web services “>
With your expressed interest in modeling, do you see that you might again work with the Object Management Group?
I know [OMG CEO] Richard Soley; Ive spent a fair bit of time with him and we have talked about that. It is not out of the question, although OMG has a bunch of standards bodies. I should be precise on that. Microsoft does work with the OMG on some of their vertical standards, but I presume you mean specifically around the UML?
In terms of modeling, Ive learned to never say never. I certainly think that if UML is interested in a platform-agnostic implementation of a modeling infrastructure, then thats something we continue to have discussions with them about. Right now UML is fairly based on the MOF [Meta Object Facility], which is based on IBMs Ecore, which is based on Java.
So I mean there are a lot of issues we have with that in terms of a platform and a language-implementation perspective, but I can imagine us someday in the future working on this. Because, absolutely, we will make a significant investment in modeling.
I also think that its not just the OMG. I could very much imagine the W3C [World Wide Web Consortium] or OASIS [Organization for the Advancement of Structured Information Standards] getting into the game in terms of realizing when they define a standard, they actually want to define the metamodel that goes along with it. So you can imagine people defining domain-specific languages for Web services coming out of OASIS or the W3C.
So as I see it, 10 years from now modeling will not be reserved for the priests in the organization, nor will it be this thing done on the side that requires a special organization that is the only group that does modeling. I think it will become pervasive and that anybody who is doing technology standards-based work will want to describe the meta-models or tooling infrastructure for their specific standards. And then I think well have a real ecosystem.
Is there anything else you wanted to close with?
I do have one thing I want to say. One of the things I react really viscerally to is people saying, “Well, this is Microsofts first instance into the team tools business; therefore theyve got a lot to learn.” And I react so strongly to that because in the 16 years Ive been at Microsoft we have some of the largest, most complex teams and most complex integrations among teams that Ive seen anywhere in the world. And a large percentage of what we are shipping is directly based on stuff weve been using internally for anywhere between five to 15 years.
So, the notion that … Id love to have a discussion with people around what do we really know about team development. I feel that people need to understand this is based on many, many, many years of very large and very detailed teams and coordination among those teams—and trying to drive that collaboration and trying to drive that quality.
Check out eWEEK.coms Developer & Web Services Center at http://developer.eweek.com for the latest news, reviews and analysis in programming environments and developer tools.
Be sure to add our eWEEK.com developer and Web services news feed to your RSS newsreader or My Yahoo page