 Video streamVideo streamVideo stream |
 |
 |
|
|
|
| Question indexQuestion indexQuestion index |
|
|
|
|
|
| Interview transcriptInterview transcriptInterview transcript |  Discuss this interviewDiscuss this interviewDiscuss this interview |
|---|
|
My name's Keith Short and I'm an Architect in the Visual Studio Group at Microsoft and I've been in the
group for about two years now and particularly in that part of it that is building tools for the enterprise. So
we're the part of Visual Studio that is really focused on building tools that are used in typical enterprise
development shops; people who are building large commercial systems. So, we're looking for whatever we can put
into Visual Studio to make the job of those guys much easier. Well, specifically, as you know, Visual Studio is a very good place to do the code and edit and debug
cycle. But we recognize that's not enough for most enterprise developers but we need to provide them with some
other tools that helps them solve the kind of problems that they're interested in. Or, obviously the one we're
very interested in bringing into Visual Studio for the Whidbey release, which is Visual Studio 2005, is some
modeling tools, which we think can really help developers do the job that they're doing in a very interesting
way. Well, it's a very fair question Ted because, in fact, I've been around the case tool industry, pretty
much since it began in the early 80s, so I bare some of the burdens and scars of some of those early efforts.
And in fact, a number of the members of my team, who are focused on the new tools we are bringing into Visual
Studio, have also got a long history of having built case tools in the past. So, between us, we've got a lot of
ideas about what not to do, and how not to repair some of the mistakes of the past. Ted: We forgive you, that association with the case tools. But, of course, it's vital that we've been able to assemble a team who have got that fantastic
experience, because we know there's a lot of reasons that case tools were not successfully utilized by
developers en mass. I think one of the key reasons was that if you look back in the early 80s, late 80s, then I
think a lot of the case tools (are) really trying to do (too) much; they were trying to raise the level of
abstraction to very fancy diagrams and using those to generate large amounts of code that then became quickly
out of synch with those diagrams. So, of course, most developers react pretty strongly for that, faced with the
choice of maintaining diagrams or maintaining code, pretty obvious what they chose to do. A lot of faults of those tools was they tried to be too much. They tried to get to a level of
abstraction, the problem developers were trying to solve, but really didn't hit the sweet spot, and that's
something that we really want to try to avoid with the next generation of modeling tools that we're building.
I'll give you and example for what I mean. One of the tools that we're going to eventually deliver as
part of the White Horse Project, which is the code name for the modeling tools that we've been working on for
Visual Studio 2005, one of the tools that we've been building is a tool to help people build applications from
Web services. Well, you might ask me: Well, but I can do that today in Visual Studio. That's a very good question. Of course you can. Visual Studio is a great place to build implementations
of Web services. Well, if you've got a lot of Web services that are communicating together, and we believe
that's the kind of application structure more and more of our customers are turning to, as they start buying
into service oriented applications. So, today, if you wanted to look at a Visual Studio solution, say, that contains a number of Web service
projects that are related in some way, you have to read code files and ASMX files, and config files, maybe WSDL
files. You have to piece all of that information together yourself. One of the things we want to do is have a
tool that can look over a solution and visualize a relationship between a set of Web services; and that's
adding value to what a developer does. But it doesn't stop there. If you think of the concept of a Web service, say, which is something that
you and I can have a conversation about. We can describe the idea of a Web service and what it means in a
service oriented application. But if you look inside Visual Studio, and I'm pretty sure this is true of other
development environments too, you'll find that that concept has been scattered amongst a number of files. And
the solution, the configuration file, the WSDL file, the C# or VB files that-- It's not physically materialized anywhere, it's scattered amongst all of these other artifacts, and the
solution as we would say. And so one of the consequences of that is that if the developer needs to rename an
aspect of the Web service or the Web service class, for example, it's up to him to manage the synchronization
of that rename across all those other artifacts. So, we really need to fix that. One of the things that we've done inside the White Horse tools, the Web services design tools,
specifically, is because we have, in effect, materialized the concept of Web services, a box on the diagram. We
can now manage the relationship that box has with all those other files and we can have an engine in our design
at runtime that can manage those name changes across all those files. So there, I would argue that just two simple cases are the visualization and keeping documents in synch.
So, we've added value to the developer, we've complemented what the developer can do already, and thereby made
models, or modeling, an interesting tool for developers. Well, it's a good question, I think it's different in one very significant way, and I'll go back to my
example of Web service if you don't mind. So we can continue on with that one. If you think about the amount of code that we generate from, say, visualize a diagram surface that's got
two boxes on it and a line between them representing the communication between two Web services. Now, what are
we actually generating from that piece of information? Well, we're generating a lot of files and the solution,
as I've already said, we're generating project structures; we're generating the ASMX files, WSDL files will
follow, configuration files, and so on. But we're not generating a lot of logic, not a lot of code logic, we're
generating some header, some outlines that-- Yes, skeleton code. But we're going to keep that in synchronization. So, in effect what we're doing is
to say to ourselves: Well, the ASP.NET framework itself is describing itself to us, using the concept of Web
service; it's materialized that in a single object. We can do that in the design and manage the
synchronization, but the amount of code that we have to generate is actually quite minimal. We're generating a lot of things besides, but we're not generating rings and rings of code, which is one
of the flaws of the earlier case products where you were taking some higher level specification of an activity
flow diagram, or class diagrams and trying to generate a lot of structures that could be derived from those
pictures, but weren't a one-to-one correspondence. In the case of the Web services I've been describing, think of that as just the concept of the Web
service having a one-to-one correspondence, albeit with many artifacts in the solution. So, the code generation
problem is actually much, much simpler, and it's been looking much easier for us to keep those things in
synchronization afterwards. So, we don't say that the diagrams--that the design that we are going to ship with Visual Studio 2005
are UML diagrams. And there's one very important reason why we haven't done that. If you take a look at the
great work that the designers and the evangelists of UML in the last 5, maybe 10 years now, a lot of that work
has been on converging diagrammatic notations. Again if you think back to the mid 90s, you had all kinds for
different shapes and figures that represented a class or a package--I think it was pretty chaotic, yeah--and I
was even involved in the UML 1.0 efforts of trying to co-ordinate some of that stuff and it was fun. And I think the industry achieved a great breakthrough with convergence on notations. And I think now,
if you look at where UML's been utilized, and very, very successfully in the industry development projects,
it's mostly in the area of documenting interesting concepts around the development process. So, people who are
building use cases are building use case diagrams and pretty much everybody in the world now uses exactly the
same kind of figures for those. Same for classes, same for activities and so on. Where UML has not been successful was producing--is really making a big impact on what software
developers actually do. Now, in fact, if you think of a use case diagram, you don't really generate code from a
use case diagram. If you think of a high level activity diagram, again, a very powerful communication tool, a
very powerful documentation tool, but you don't, generally speaking, not many people anyway, generate real hard
code from those pitches. No, indeed. Most code generated from UML tools is in fact class diagrams which can generate all kinds of
classes. But then you have another problem because UML itself defines a type system; it's got a set of concepts
that it understands as to what a class needs. Ted: Right, the meta meta-model, or something like that. Well, the meta-model, as we in this business would say, of UML in the area of classes are quite well
defined and has it's own set of types that it needs to define it's own UML class diagram. Well, typically, that
does not have an exact match with the type systems of programming languages used today, like Java and C#. So
when you translate from a C--from a UML class diagram, into one of those programming languages there's
generally very little lost. And good UML tools try to keep those in synch, but it's quite a complicated problem
to do that. So, one of the things we have done in the White Horse project is to say: Let's not do that, let's remove
that problem of trying to keep a separate type system from the programming languages, in synch. Let's instead
say: How can a model add value to a developer's tasks? And one answer is to say, code visualization. So, if you can visualize a piece of code that already exists as a class diagram and simply have the
underlying class system of the diagram the same as the programming language, then you've got 100% fidelity. You
can make sure that you can keep those synchronized all the time and still make the pictures add value to the
tool. No. Because notationally they are going to be very similar. So our class designed diagram uses mostly
UML in the notation. So, if you're familiar with looking at a UML class diagram, you'll have no problem looking
at a class diagram that we're going to offer you. And we think that that will considerably add value in the
means of understanding the structure of your programs. And, indeed, being able to structure the programs before
you generate the code and that's the kind of two way thing that is quite important. So, that's a value proposition that we think we've got over the more generic use of UML, particularly in
the area of class modeling, but I would emphasize, we think that the UML notation, for some of these more
documentation oriented diagrams is just right on. And although we are not providing an implementation of those
designers, or diagrams, initially in Visual Studio 2005, we fully expect those fully to be built by our
partners on top of our underlining framework as time goes on. Nevertheless, when we ship it with Visual Studio 2005, we still will be supporting the UML diagrams that
ship with our Visio product, for those customers that still want to build those. Use case diagrams and pretty much the full range of diagrams that are very useful in this kind of
communication, or sketching, or concept exploration, or documentation. Well UML has actually been very, very
successful. But when you get right down close to code, or close to project structures we think you just can
beat having very purpose built modeling languages that understand exactly what the platform is offering.
That's really the story with White Horse; we're trying to build the class designers, as I mentioned, the
Web service designer, which is a very close reflection of exactly what's in a Visual Studio solution that's
building Web service projects and so on. Yes, in a way that I will explain. The designers that I've been mentioning, and we still have one more
to talk about, but the Web service designer and the class designer, those are built on a framework that helps
us build model driven design tools. We've used it to build those two plus the other one we'll talk about in a
moment. But that framework itself is kind of in its version 2. We used that framework to construct the
orchestration tool that shipped with the recent RTM of BizTalk of BizTalk Server. So, the orchestration
designer for that product was built on our framework BizTalk 2004; so the new orchestration designer was built on the first generation of that framework. So,
you could argue that that is another instance of a well structured model driven development tool that offers a
graphical editing experience, over an otherwise, quite complicated schema--the BPEL schema. Looking forward, one of the things we want to do is to make sure that people who are using BizTalk, for
example, are building schedules with their orchestration design tool, when they need those schedules to be
wrapped inside a Web service, that they will have an experience on our Web service designer that will allow
them to put a little box on the Web service designer, and treat that as a wrapper to one of their BizTalk
schedules. So, we're trying to get that scenario worked out so that people will have a good service oriented
architecture design experience that will include wrappers across schedule and wrappers across legacy system
applications using our host integration service product as well. So, what we're going to ship in Visual Studios 2005 are three designers mainly. The class designer, that
we just talked about, the Web service designer, and I've been using this as an example, and the third one is a
very interesting tool. And again, just as a quick aside, it has no correspondence to anything that is in any
UML tool set today. So, this is a new domain of applying a modeling tool. And its job is to model deployment
environments, and we call it the logical datacenter designer, which is a bit of a mouth full, we may even
change that name. But its function is to describe what facilities are available for software developers to
deploy their applications in the data center. So in a diagram like this, and again it looks like a box and line diagram, but in this circumstance the
box means a type of server. So, types of boxes are confined down there in the datacenter, and then properties
of those boxes will be software that is stored on those servers, host software we would call that, and all the
settings and configurations options of those pieces of software. So, for example, if I go server that's configured with, say, IIS, with it's accompanying hundreds of
settings then the values of all those settings for a specific instance of IIS is a very useful thing to be able
to describe in a model. Because, of course, in the real datacenter, there may be dozens, or even hundreds of
physical servers that are set up in that way, but have a box that represents that configuration of host
software and hardware is a very useful aid to deployment. What I can do with this diagram is I can draw the virtual, the logical discretion of all the host
software and server types that are in my datacenter, I can set all my constraints, and all my policies, that
are going to exist as to how those boxes are connected up in terms of protocols I can exchange, how they group
in to virtual network segments and so on. So visualize a diagram that's a set of boxes with lines between them that represent types of serve,
configurations of host software and protocols and firewalls if you will. The kinds of things that I'm allowed
to flow between two boxes. So, now, with a tool like that, you can say, what I've got is a whole set of
metadata, or data about my datacenter, information that is very, very useful, and the key is how can I make
that available during design time? We think that there's a very powerful scenario that say: If the developer knows about the deployment
configurations of the datacenter then that information can be made available to him while he's configuring the
application and we have an opportunity to do a cross check, to say, Can I, in a [child] deployment, can I
actually make sure that the applications services I'm building are going to deploy on my datacenter, and if
they're not, then thank goodness I'm going to discover that while I'm doing development rather than when I try
to do deployment. Exactly, and that will be configured by people who run the datacenter, the operations staff and the
network architects and so on. We'll provide some tools to help them get that diagram built up and running but
the key idea is to make that information available to developers because now, for example, a developer is
configuring his application but perhaps gets too engrossed in getting those configuration settings set up for
his F5 experience on his machine. He may not get the security option set up correctly, he may not have his SQL
set up, or options set up in a way that they're going to be set up in the database center. So, being able to model all that information in the service diagram and then have the data available
from the datacenter, and do this validation across, or give that developer very early warning of potential
developer deployment problems, so he can fix them when they're still cheap to fix. So we call that design
preporations as a name for a scenario, and it's a key part of what we want to try to solve; a real developer
problem that we want to try to address with the White Horse project in Visual Studio 2005. Well, MDA is a fairly large vision that's been created by members of the OMG. To describe how model
driven development can be practiced inside organizations. So, it's not very specific about how you actually go
about building the applications, it simply describes the kinds of things that can go on if you're using models
to help you build applications. So, we have a couple concerns with MDA which is one of the reasons why we're not out there saying that
we're part of MDA, but right off the bat, I should tell you that there's a huge amount that we think is right
about MDA. For example, we think model driven development executed correctly can realy assist developers. Many
of the scenarios that we've talked about today are examples of how models can compliment and add value to all
the developer's doing. In contrast, I think, as we agreed--we agree that OMG, in general, model driven
development can be a very powerful aid. We probably differ a little bit in how we think people should go about it. And you've heard me describe,
pretty forthrightly, that we're starting from very pragmatic developer problems like: How to code, how can we
materialize useful concepts like the Web service in a model that's very close to the underlining implementation
of a Web service, how can we address this design for properations, or the deployment problem, and so on.
So, we've started with models that are very pragmatic because then we know we can then get relationships
[to bend] those modeling languages cause that's what those are, and the underling development artifacts, and do
a good job of keeping those in synch, avoiding the old case problems of old, and generally just adding value,
straight out of the box to the developers who've got real problems. Now we just start to get into some of the higher conceptual modeling errors where you start to talk
about business processes or business capability, or much more higher level concepts. It starts getting a little
bit vaguer and we would say that one of the things you must do is start to build those models up, you've always
got to have in mind something that you can relate them to. So, for example, in our case, the Web service interconnection designer that we have, we know exactly the
very precise definition of those concepts. We can state very precisely how each of those concepts map or
transforms into code, configuration files, and so on. And we can make sure that that works well. What we don't want to do is rush headlong into an imprecisely specified high level model with
imprecisely defined links to other things in a vague way, because at that point we don't think you're doing
model driven development properly; you've moved into this era, or this space, of just being documenting higher
level forms and hoping that they're going to somehow relate and synchronize with low level implementation
artifacts. So we think model driven development really works well if at each layer of abstraction you picked
something that is very small scoped set of ideas, like a business process, and define that very precisely, but
at the same time define very precisely how these concepts relate to implementation level details. A good example would be a business process model which describes what a business is actually doing, or
plans to do, and you will find when you look at most realistic business process models that not all of those
activities, or whatever, you describe in that model are going to be implemented for a start. Some of them may
be manual procedures, so already you're going to pick and choose. And by the way, they're not always going to
be implemented by a process management engine like BizTalk. Some of them might be, but some of them can't be
because of the way the process is. So, the point being, I need to be able to describe variable mappings to
interesting artifacts and provided I can do that I have a firm basis to stand on at that level of abstraction.
Well, we think bottom up is good because it's starting with real developer problems. But we certainly
acknowledge that models can have a very big impact on some of these top down errors. But if you're going to use
those models for anything other than documentation, if you actually want them to be first class participants in
designing the software then you've got to make sure that they're very precisely defined and that the
relationships they have with other things are also very precisely defined. And that, I think is one of the things that's sort of lacking in the MDA story, is that in the MDA's
reliance on the UML models which are not very precisely defined in all cases, makes it a little difficult to
see how that is all going to pan out and make a real impact on how software is actually developed over and
above how software might be thought about and documented. And that, I think, is the crystal difference between what they're trying to do, and what we're trying to
do. So, in some ways, we want to be very pragmatic, solve real developer problems, and make sure that the tools
that we build really contribute in very effective ways to software development. Well, I think the first thing I would say is that we've got a lot of features that we've got to build
out on the tools that we're building because we're just beginning this process of how models contribute to
development, so we have to fill that out. And then I think where we're looking beyond that is to take what we've done for the three tools that
we've built for Visual Studio 2005 and start to see how we can build higher level languages from those;
modeling languages which address higher level concepts, like business processes, as we've been discussing, and
really understand how to make it easy, not just for we, at Microsoft, to build those tools, but for our
partners and indeed our customers to build customized modeling languages that help them solve their very
specific problems in the kind of apps that they're trying to build. So, we think there a very interesting future for this technology is to encourage people not to think
poorly of modeling as they've done in the past, but to be able to see so much benefit in the world of modeling
as it applies to real problems, that they would embrace it and indeed customize tools that we supply and in
fact, ultimately build their own modeling languages that are very specific to problems that they have. We think
that that is a great possibility and would move the industry on and not change a much better, stronger
engineering discipline around software development. Okay. |
