Original URL: http://www.theregister.co.uk/2007/03/27/software_factories_greenfield/

Microsoft’s software factories

We talk to Jack Greenfield about the future of Visual Studio

By Tim Anderson

Posted in Developer, 27th March 2007 06:02 GMT

At Microsoft’s Architect Insight conference in Wales this month, Microsoft software architect Jack Greenfield tells us about a BMW factory which rarely makes the same car twice. It is an example of mass customization, handling millions of variations within an automated process. Could the same apply to software development?

“I know that software is not exactly like anything else, but we flatter ourselves if we think it is radically different,” he says. The challenge of software development is in meeting unique user requirements with general-purpose platforms and tools. “We ought to be able to produce a wide range of variants from a pre-defined set of parts, plans, and components, largely by assembly but also with some customization.”

This is the essence of software factories, which Greenfield defines as “reusable assets that support the enactment of custom processes.” In the context of Microsoft’s platform, this means a Visual Studio add-on, supported by templates, libraries, tools, wizards, models, patterns and guidance documentation. He believes that between 40 per cent and 80 per cent of development effort can be automated.

pic of Jack Greenfield, Software Architect, Enterprise Tools, Microsoft

Jack Greenfield

Is this just another bunch of tools and wizards for Visual Studio? Not really. Greenfield insists that his team is building a platform, rather than merely supplying tools. It turns out that this has been a matter of internal debate: "Rick LaPlante, who did Visual Studio Team Suite, got funding to do modelling," he told me.

"The charter for the group was to build tools for web service design. Some of the folks involved had an interest in how logical designs of the architectures of systems map onto the logical designs of the infrastructure to which they will be deployed. Hence the tools in Team System, which were about design for deployment. There are really four designers, and in our parlance we’d say they are four viewpoints, four aspects of the problem being modelled.” This was the project code-named White Horse.

At the same time, the team “had a much broader and longer vision than was being realised in the group”, according to Greenfield, and wished to move beyond the confines of the charter. Rather than supply just four viewpoints, the team wanted to make it into a tool for creating viewpoints. “We said, inside those white horse tools which have been built as a monolith there are some frameworks hiding.

We’d like to harvest them out and wrap them with authoring tools so that third parties can build their own designers.” This is what became the Domain-specific Language (DSL) Tools, released as part of the Visual Studio SDK. At that point, there was a management change, and the team reverted to focusing only on the original White Horse tools; everything else was on ice.

Greenfield expresses frustration with the “White Horse” tools as shipped. ”It was discovered that architects use those tools maybe a couple of weeks a year. They are not extensible. They describe a few interesting viewpoints in certain kinds of systems, but it wasn’t the platform that people needed, which they could customize.” The outcome was that Greenfield's team got together with the team responsible for “Patterns and Practices”, architectural guidance for software development, and returned to the broader platform vision.

The means of production

“It's now been recognized that tools for architects have failed in the marketplace, repeatedly, because architects don't want anyone else's way of doing things, canned. What they want is something that's fluid and can evolve. That means we're building the factory platform and runtime, and evolving the DSL tools. We're also now working with Patterns and Practices as a provider of instances. The idea is that the instances they provide will be customizable and extensible, and the factory architecture is such that they’re building blocks, so rather than focus on composing components and services, we focus on composing the means of producing components and services,” says Greenfield.

What Greenfield calls a “runtime” is the piece that takes the factory that you have acquired, written or adapted, and executes it within Visual Studio. Currently, this is called the Guidance Automation Extensions, or GAX. The factory authoring tool is called the Guidance Automation Toolkit (GAT). Using these tools, you can create automated activities called Recipes, along with wizards and templates. The DSL tools let you add visual modelling to your factory. These pieces are used by the four software factories now shipping, which cover Web Clients, Smart Clients, Mobile Clients, and Web Services, and are free downloads. However, Greenfield describes the current runtime as “primitive” and promises something better in future.

There is also the question of why Microsoft is not using the standardised Universal Modelling Language (UML) and its associated Model-Driven Architecture (MDA) to speed productivity. “We are the UML guys, that’s the funny part of it,” says Greenfield. “I was one of the chief architects at Rational; I spent a lot of time deeply steeped in the UML and in the committee work in the OMG. Other guys on team go deeper than I do. Steve Cook, for example, was really the father of OCL [Object Constraint Language], and wrote the green paper for the family of languages which spawned the UML 2.0 effort. We’ve got deep roots.”

U and non-U

Despite (or because of) his background, Greenfield is now dismissive. “The UML is a collection of useful abstractions,” he says. “Unfortunately it’s been peddled as a universal modelling language, but the U never stood for Universal. We subscribe to Michael Jackson, author of Problem Frames, who says that there is no such thing as a universal solution. It's a childish approach. This is where the Universal Modelling Language marketing pitch fails. UML was never properly extensible. It also has the problem that it was designed by a committee.

Aside from that, things like state charts and sequence charts and activity graphs are very useful abstractions. UML becomes for us a repository of useful notational conventions and core abstractions, but in its form as packaged and delivered, not terribly effective. We view factories versus MDA the same way. MDA says you’ve got three viewpoints, CIM, PIM and PSM. The same viewpoints apply to everything, whether you’re building eBay or a mobile device application. We don’t buy that. They’re different things.”

It is easy to criticize the UML; but can Microsoft show that its new software factories are more effective than previous efforts to improve developer productivity? Greenfield mutters about customer feedback, and then talks about how packaged applications like SAP have replaced development from scratch in ERP (Enterprise Resource Planning).

"The general principle of having pre-defined architectures, components, skeletal applications and pre-defined database schemas, and a process to adapt that to a customer - that’s working,” he says. That’s true, but it’s more a validation of “buy versus build” than proof of the viability of software factories. This considerable effort may prove no more than an interesting experiment.

That said, it's a bold and intriguing vision. Greenfield will not be pressed on times or dates; he merely says that this is where Microsoft is heading

Perhaps it is reasonable, then, to expect a more fully realised version of the current factory platform in the high-end editions of the next Visual Studio. ®