Microsoft's Burley Kawasaki: How modeling will change programming

Making modeling mainstream
Insofar as a veteran professional developer will be capable of embracing the new concepts of Oslo and modeling, there will have to be some degree of mindset shift. Though Microsoft representatives and executives have talked recently about developers' ability to leverage their existing knowledge bases to extend themselves effortlessly into the wonderful realm of modeling and services, some of that baggage -- we anticipate -- will probably need to be shed.
So we asked Microsoft's Oslo chief, Burley Kawasaki, just what the extent of that shift in mindset will be.
BURLEY KAWASAKI, Dir. of Product Management, Connected Systems Division, Microsoft: I think...a lot of the tools in the products that developers already use are pretty model driven, but they're also using their own silo of models for a particular domain. System Center is a great example; it has a lot of models about what's in the data center. It's all declarative, it's not hard-coded anywhere, and it's defining all of the things that you do if you're an IT professional. If you're a developer, there's models that describe the ASP.NET MVC structure of an app; or you might have a model that defines, using Silverlight, the presentation layer; or if you're building workflow using Workflow Foundation, you're building a model of the workflow. Each of these models are defined using some different syntaxes, different tools, they're stored in different ways in these silos.
So one of the opportunities we have is trying to take a lot of the work that's been done over the past five-plus years in each of these silos, and really trying to generalize this into a general-purpose modeling platform that...takes us more into the mainstream. Right now, modeling has been largely sort of a "specialist technique," used up front in the design phase of a project, but then you'd typically print something off and then the developers will go off and use their own traditional development techniques. So modeling hasn't been mainstream, and we think that for it to be mainstream, it has to be actually taken and pulled into .NET, pulled into the platform in a very deep way.
The way we think about that is actually making models as an executable notion inside .NET. So you'll hear us talk about executable models as really the sweet spot for Oslo, and that's, I think, one of the defining things that really will advance modeling into the more mainstream development community in particular. It's not something sort of off to the side, but it's really a first-class part of the app that executes this in the same way that their code executes.
SCOTT FULTON, BetaNews: So I'm assuming that developers, especially those with the new Visual Studio 2010, even as far as the Standard Edition, they're going to have a little more modeling in front of their face more often.
BURLEY KAWASAKI: Well, you've heard about some of the UML support in the Team Architect [version], and then also, we're contributing some enhanced modeling, visual modeling designers for things like workflow and for other particular pieces that a developer needs to model -- a user interface component, a workflow, a service.
But in addition to that, one of the real breakthroughs with Oslo is this (we actually stumbled into this by accident): We set out doing what we thought was the traditional modeling play, which was very heavily oriented around a visual designer. So we worked on taking the models stored in a repository, and then allowing a visual editor to edit them and let them change them and collaborate. But when we actually engaged our own developers, they wouldn't adopt it. And the reason they wouldn't is because they preferred to be in a textual editing mode inside the type of text editing paradigm that they're used to.
So that led us to create this modeling language, code-named "M," which is really one of the ways that you can take modeling mainstream. This allows you to sit in front of Visual Studio, author something that is in the domain-specific dialect of choice -- DSLs, domain-specific languages. So I can write something that is very friendly, very intuitive, very textual, but that gets saved as a model in the repository and then, let's say, if you're a business analyst or you're an architect or a different role, you can pull it up using some of the visual tools and manipulate the same model. It really gives a much broader set of ways to engage and interact with a model, not just visually but also textually.
SCOTT FULTON: In the 1970s, IBM came up with a concept called ALGOL, which it had described at that time as a modeling language for prototyping high-level languages -- and at that time we were talking about FORTRAN and maybe the very early versions of the line-numbered BASIC, COBOL was certainly in there. When you're using a textual modeling language like M, what's the mindset difference between somebody who's simply modeling the algorithm and somebody who is modeling the deployment of this on a platform?
BURLEY KAWASAKI: Two things: One is the notion that domain-specific languages can be added on top of this in a very natural [way]. So think of it as sort of skins that re-skin a lower-level M language for different domains. If I'm in the Web domain, I may have a domain that targets an MVC type of app; or if I'm in a service-oriented domain, I may have a DSL that targets that kind of app. So we found that people like to live in, sort of, the problem space that they're trying to solve, and that's one of the things that we found allows people to very incrementally step into this with high productivity. The DSL concept -- both textual, but also visual DSLs, being able to define something that is very tailored for just the kind of model that I'm trying to edit, is pretty important.
The second piece that I think is particularly innovative is the notion of, this is a model that we intend to execute. So to do that, the model has to be able to target, for example, a runtime in a very deep and rich way. By runtime, I mean being able to target deploying over to Windows Server. Some of our Dublin work [involves] extensions to the Windows App Server runtime to allow us to take models and then execute them natively, as part of our application server stack. Windows Server is an application server environment; today it supports a lot of different types of applications, Web apps, or traditional [applications]. One of the things we're seeing, though, is the move towards these workflow-centric apps, where people aren't writing as much code but they're stringing together process and logic, maybe streaming together services, creating a sort of composite app that is more declarative than traditional programming.
So this is the style of app where we take the model out of Oslo and deploy it onto Windows Server as a runtime, and then have it execute. That's something that, within the M language, we support deeply -- the ability to transform the models out of this very abstract representation. It does give you this very abstract way to share, you and I can collaborate on a textual document. But it allows you to transform it into the particular syntax that's needed for the runtime to execute.
Another example is, a lot of models end up being stored in a database, because the app that is running needs the models or the metadata that's stored in the database at runtime. So we have out-of-the-box support for taking the models that you find in M and map them in a very first-class way into the database to enable that runtime execution.
SCOTT FULTON: Now is there some place that someone can go to find examples?
BURLEY KAWASAKI: We launched a new Dev Center on MSDN; and anticipating a lot of the questions, we not only handed out the [Community Technology Preview] at PDC, but we also put a subset of this out on MSDN. We put the full M language, we put all of the base model libraries and base class libraries in .NET.
[Also,] we're putting the M language spec under the Microsoft Open Specification Promise...to really enable the industry, people outside of Microsoft, to take it, to enhance it, to extend it. This is a license that allows them to build their own implementations, including on non-Windows platforms. So we think, if it's something that's going to show up in some point in a classroom, it has to be more than Microsoft trying to evangelize this as something that is an important thing, but we really have to get the community involved, a lot of folks in the open source community involved. We're actively engaging with the community to try to help foster the evangelism, the teaching, the training.
SCOTT FULTON: What does one have to do these days to actively engage the community, other than put up a blog?
BURLEY KAWASAKI: Well, certainly things like the MSDN Dev Center is a piece of this. It's mostly the commitment by our engineering teams to be very active in terms of the forums, the community sites, providing a lot of the help. For people in our engineering team, they've been working on this for a couple of years, so it's very clear; but to the vast majority of people in the world, they're still getting up and running and have a lot of questions. So we're going to put a concerted effort over the next few months into making sure that on the forums and the community sites that we are giving the right level of support that's needed.