Microsofts VSTS Goal: Creating a Mass Market for Enterprise Tools

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.

Resource Library:

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.